标签：#iOS

I wanted to see earthquakes the way they actually happen: as points lighting up on a spinning planet, in near real time. That became Earthquake: Live Seismic Monitor , an iOS app that renders a 3D globe of recent quakes straight from the USGS feed. No backend of my own - just the public data and the device. Here's how it comes together. The data source The USGS publishes earthquake data as GeoJSON feeds, updated continuously, at several time/magnitude cutoffs (past hour, past day, 2.5+, 4.5+, etc). Each feature has coordinates, magnitude, depth and time. That's everything you need to place a quake on a globe - no custom API required. The app polls the appropriate feed, diffs against what it already has, and updates the scene. Because USGS does the heavy lifting, the whole thing is effectively serverless from my side. Putting quakes on a globe The core mapping problem is turning (latitude, longitude) into a point on a sphere. Once you have that, each earthquake becomes a marker whose size and color encode magnitude and depth, so a glance tells you "big and shallow" vs "small and deep". Design decisions that mattered: Encode magnitude visually. Radius and color do more than any label. A magnitude 6 should look like a magnitude 6. Cluster sensibly. Active regions produce swarms; markers need to stay readable when dozens land in one area. Keep the globe interactive. Rotate, zoom, tap a quake for details. It should feel like an object, not a chart. Real-time without a server Every network-dependent app has to answer: what happens offline, and how fresh is "live"? My rules: Cache the last good feed so the globe still renders with no connection. Refresh on foreground and on an interval, and show the data's own timestamp so "live" is honest. Never block the UI on the network - render what you have, then update. Why no backend It's tempting to proxy the feed through your own server "for control". But USGS is reliable, public, and built for exactly this. Skipping a backend me

You've seen some View in every SwiftUI file you've ever opened. Now let's find out what it actually means, why it exists, and why returning a plain protocol doesn't work the same way. Fair warning: this topic is genuinely one of the more brain-bendy things in Swift. I'm going to tell you upfront that you don't need to fully understand the internals to keep going — but you do need to know it exists and roughly what it's doing, because you've already been using it every single time you've written a SwiftUI view. That some View in every SwiftUI file? That's an opaque return type. And now we're going to actually understand what that means. 🍥 Let's Start With Something That Works Two simple functions: func getRandomJutsu () -> Int { Int . random ( in : 1 ... 100 ) } func getRandomSuccess () -> Bool { Bool . random () } Both Int and Bool conform to a protocol called Equatable — which means they can be compared using == . So you can do this: print ( getRandomJutsu () == getRandomJutsu ()) That works fine, comparing two random integers. Now, since both return types conform to Equatable , you might think: what if we simplify both functions to return Equatable instead of their specific types? The Thing That Doesn't Work func getRandomJutsu () -> Equatable { // ❌ Int . random ( in : 1 ... 100 ) } func getRandomSuccess () -> Equatable { // ❌ Bool . random () } Swift refuses this with an error message so confusing it might as well be written in ancient runes: "protocol 'Equatable' can only be used as a generic constraint because it has Self or associated type requirements." Here's the actual problem in plain English: if both functions return Equatable , Swift loses track of what specific type is coming back. And if it doesn't know the specific type, it can't know whether two Equatable things can actually be compared to each other. Think about it: an Int and a Bool both conform to Equatable , but you can't compare them with == . That doesn't make sense. Swift isn't going to let y

MVVM with swiftUI When learning SwiftUI, one of the first architectural patterns you'll encounter is MVVM (Model-View-ViewModel). In this tutorial, we'll build a simple weather application that consumes the OpenWeather API while applying MVVM, dependency injection, and protocol-oriented programming. By the end, you'll understand not only how to structure the project, but also why each layer exists. This is the link for the OpenWeather API https://openweathermap.org/api . What you'll learn By the end of this tutorial you'll know how to: Structure a SwiftUI project using MVVM. Consume a REST API using async/await. Apply dependency injection using protocols. Display loading and error states. Keep Views focused only on UI. This is how the data flow looks. User taps "Search" │ ▼ ┌──────────────┐ │ ContentView │ └──────┬───────┘ │ await fetchWeather() │ ▼ ┌────────────────────┐ │ WeatherViewModel │ └─────────┬──────────┘ │ ▼ WeatherServiceProtocol │ ▼ ┌─────────────────┐ │ WeatherService │ └──────┬──────────┘ │ ▼ OpenWeather API Project Structure WeatherApp ├── Configuration │ └──AppConfig.swift ├── Models │ ├── Main.swift │ ├── Weather.swift │ └── WeatherResponse.swift ├── Services │ ├── WeatherService.swift │ └── WeatherServiceProtocol.swift ├── ViewModels │ └── WeatherViewModel.swift └── Views └── ContentView.swift Configuration contains application-wide constants such as the API key and base URLs. Models contains the data structures used to decode the API response. Services is responsible for networking and fetching data. ViewModels contains the presentation logic and exposes data to the UI. Views contains the SwiftUI interface. On the AppConfig file, we are going to keep static info, just like the base URL, API key, etc struct AppConfig { static let apiKey = "YOUR API KEY" static let baseGeoCodingAPIURL = "https://api.openweathermap.org/geo/1.0/direct?q=" static let baseURL = "https://api.openweathermap.org/data/2.5/weather?&units=metric&lat=" } Designing the UI Befo

A bug in how Apple implements its Private Relay feature, which in theory masks users’ IP addresses from the sites they visit, can reveal users’ real IP addresses.

On our new Real World AI stage, we’ll be focusing on the intersection between the digital and physical, and all the ways we’ll continue to see a blending of the two.

Protocols let you define what a type can do without caring about what it actually is. Once...

PR #5421 adds RichTextComponent , a read-only component for formatted application text. It supports headings, inline styles, lists, links, and images without embedding a web view. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . A SpanLabel applies one style to wrapped text. A BrowserComponent renders a complete web page. RichTextComponent covers formatted document content between those two cases and participates in ordinary Codename One layout. Rich text inside a scrollable container A common screen mixes formatted text with buttons, images, forms, and other Codename One components inside one scrollable container. A BrowserComponent is a poor fit for that layout because it owns a rectangular native surface and its own page viewport. The browser's document height does not naturally become the height of a child inside the parent Codename One layout. RichTextComponent measures wrapped runs for the width it receives and reports the corresponding height. In the default SizeMode.SHRINK , it behaves like a SpanLabel : the parent container scrolls the rich text together with the surrounding components. SizeMode.SCROLL is available when the rich text should keep an assigned height and scroll its own content. The read-only view and editor agree on paragraph attributes, inline styles, links, image runs, and wrapping because they do not maintain competing renderers. Supply the format you already have HTML is not the only input: RichTextComponent view = new RichTextComponent (); view . setMarkdown ( "# Trip summary\n\n" + "Departs **09:40**, arrives *11:15*. " + "See the [itinerary](app://itinerary).\n\n" + "- Window seat\n" + "- Carry-on only" ); form . add ( view ); setContent(...) accepts RichTextFormat.HTML , MARKDOWN , ASCIIDOC , or RTF . The model covers headings, emphasis, inline code, links, images, lists, quotes, literal blocks, p

PR #5386 adds a pure Codename One text-editing path. EditField , RichTextArea , and CodeEditor can now keep their document, selection, and painting inside the lightweight UI while each port supplies keyboard and input-method events. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . Text input must handle virtual keyboards, hardware keys, autocorrect, dictation, marked text from an input method editor, bidirectional text, selection, clipboard formats, and accessibility geometry. Codename One traditionally delegates that work to a native platform field placed over the lightweight component during editing. The overlay remains the default for TextField and TextArea . It can create a small visual jump, and it cannot participate in lightweight painting for syntax highlights, rich runs, masks, inline images, or a custom selection model. The port sends text operations instead of key codes A soft keyboard does not type keys. It commits words, replaces a marked composition range, deletes text around the caret, and changes selection. Dictation may insert a sentence without producing one key event. The new TextInputClient contract models those operations: commitText(...) inserts final text. setComposingText(...) replaces the active marked-text range. finishComposing() accepts that range. deleteSurroundingText(...) implements virtual-keyboard deletion. onKeyCommand(...) carries navigation, selection, clipboard, undo, and redo. Geometry queries locate the caret and selection for candidate windows and accessibility. All offsets use UTF-16 indices. That matches Java String , Android Editable , and Apple string APIs. The document normalizes line endings before it updates selection, undo history, formatting runs, or the state returned to the platform. The port still owns the keyboard session. Codename One owns the document and what appears on scr

If you’re looking to cut back on screen time and get a little more active, here’s a roundup of the apps that might help.

What I wanted I'm building a system where all my daily records live in Notion, so I can point an AI at it and get feedback. Goals, tasks, daily logs, finances — those are all manual entry, and that's fine. But one day it hit me that weight would be nice to sync automatically. The requirements were simple: Every morning, my weight and body fat percentage get appended to a Notion database as one row No manual typing That's it. My scale is a Withings Body Smart. The design I picked first This one: Scale → vendor app → Apple Health → iOS Shortcut → Notion API I chose Apple Health as the hub for these reasons: It doesn't depend on the scale model. As long as the data lands in Health, the same implementation works for any vendor. No server required. A time-based Shortcuts automation handles it end to end — no always-on machine, no cron. Free. No extra subscription. Extensible later. Anything that's already in Health — steps, sleep, heart rate — could be added the same way (if I ever wanted to). Generic, zero cost, extensible. The design looked sound to me. Implementation Here's what the Shortcut looks like: 1. Find Health Samples [Weight] latest, limit 1 2. Get Details of Health Sample [Value] → variable Kg 3. Get Details of Health Sample [Start Date] → variable SampleDate 4. Format Date yyyy-MM-dd → variable Ymd 5. If Ymd == today 6. Text ← build the JSON 7. Get Contents of URL ← POST to the Notion API Step 5 matters. Without it, on a day you don't step on the scale, yesterday's weight gets appended under today's date . Here's the JSON built in step 6: { "parent" : { "database_id" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" }, "properties" : { "Date" : { "title" : [ { "text" : { "content" : "@@YMD@@" } } ] }, "Measured" : { "date" : { "start" : "@@YMD@@" } }, "Weight kg" : { "number" : @@KG@@ }, "Body fat %" : { "number" : @@FAT@@ } } } (My real database uses Japanese property names. What matters is that they match your database exactly.) I write this as a plain string in a

Every recorded mobile test I have ever inherited died the same way: someone moved a button. The recording said "tap at (340, 712)". The redesign moved that button up by one row, and the test kept tapping — now on empty space, or whatever happened to land there instead. It didn't fail right away. Three sprints later, it started failing in confusing ways, and by then nobody trusted the suite anymore. The fix isn't a better recorder. It's recording a different thing: not where you tapped, but what you tapped. That needs an element tree, and for a while we didn't have one. tapflow is an open-source, self-hosted tool that streams iOS simulators and Android emulators into a browser, so a whole team can test builds without installing anything. Until now, everything it moved was pixels in one direction and taps in the other. This post is about getting an element tree out of a simulator with no window, on both platforms. What we do with that tree — replaying flows that survive a redesign — is the next post in this series. The automation axis this feeds — the flow runner and the MCP server — is experimental . The manual browser QA path is the mature one. The constraint: no WebDriverAgent, and no simulator window tapflow already injects touches into the iOS simulator without WebDriverAgent — it loads CoreSimulator.framework and pushes HID events through SimDeviceLegacyHIDClient (that story is ep.1 ). Streaming reads the framebuffer IOSurface directly. Neither path needs Simulator.app on screen, and that's deliberate: an agent Mac in a closet running four simulators shouldn't be babysitting four windows. So whatever we used for the tree had to follow the same rule. No WDA to install and keep in sync with Xcode. No simulator window on screen. Our first attempt ran into exactly that limitation. macOS exposes an accessibility API ( AXUIElement ), and Simulator.app publishes its content through it. We wrote a helper around it, and it worked perfectly on a developer's laptop. On the

“Supported on iOS, Android, desktop, and web” sounds useful until you need one method on one target. Does WebSocket work on watchOS? Which Linux architectures do we build? Was the JavaScript media test green this week, or did somebody update a table six months ago and forget it? What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . PR #5389 turns those questions into the Codename One Port Status page . It maps 49 user-facing feature groups across 10 portability targets to current conformance results, environment data, skip reasons, and the date of the run. The table is an output, not an opinion The HelloCodenameOne suite already exercises APIs and screenshot goldens on Android, iOS, tvOS, watchOS, JavaScript, native Linux, native Windows, and Mac Catalyst. The missing part was a contract that translated thousands of test cases into a stable public vocabulary. The new conformance mapping connects registered tests and screenshots to rows such as networking, media, databases, maps, notifications, input, accessibility, and 3D. CI normalizes each port's result into the same report format. A publishing workflow writes the latest reports to a data-only branch. The website consumes those reports and renders the matrix. The page currently renders 490 feature cells. Ten targets appear because architectures and renderer variants matter. iOS Metal and legacy OpenGL are separate evidence paths. Windows x64 and ARM64 are separate. Linux x64 and ARM64 are separate. JavaSE is deliberately excluded from the public portability matrix. It is the simulator and development runtime, not one of the deployed native targets the table is meant to prove. A green cell has a chain of evidence Each status report records the commit, environment, registered tests, outcome, duration, and skipped cases. The website data also records the runtime used for browser and

I've been following WWDC since 2011* and over the years I've developed my own process for watching sessions. Over the past 15 years, I've gone through all the stages from denial (I missed all the videos, for example, in 2014, when I couldn't accept Swift's appearance), to bargaining ("I still CAN watch all of them!") and finally accepting and creating my own approach to watching WWDC. So here's my current approach: I try to watch Keynote and Platforms State of the Union at the time of their live broadcast or in the early days. When all the sessions become available, I sit down and go through all the titles and descriptions and choose what I will watch. All sessions fall into 4 categories: Essential is a must watch and should never be missed Nice To Watch is something interesting to me personally and may be applicable to what I work with Only If I Have Time is for optional sessions that interested me, but if I skip them, then nothing terrible will happen Everything else Thus, I clearly identify a fairly small set of sessions that I definitely need to watch, usually it's about 10 sessions and I don't feel any FOMO or pressure that there is so much new and how and when to watch it all. Most of the time, it takes me all summer to slowly watch everything from Essential, a few (or all, it depends) Nice To Watch, and sometimes a couple, and sometimes nothing at all from Only If I Have Time. An important rule for me is to watch Essential first. Then I can do whatever I want. Another personal kink of mine is to watch the sessions in the order of their numbering. For example, in my Essential category, the very first video is 227. Create UI prototypes using agents in Xcode , and then 258. What’s new in Xcode 27 and so on. So, here is my personal list of WWDC’26 sessions, divided into these categories: Essential Create UI prototypes using agents in Xcode What’s new in Xcode 27 Xcode, agents and you Get the most out of Device Hub What’s new in Swift What’s new in SwiftUI Moderni

Apple says it won't limit the capabilities of devices leased through its new Upgrade program if you miss a payment. In an emailed statement to The Verge, Apple spokesperson Brian Bumbery says, "There will be no restricted mode and/or there will be no limitations put on device functionality due to missed payments or default with […]

Accessibility has become personal for me. I am getting older, and large type is no longer an abstract preference somebody else needs. It is how I read a phone comfortably. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . I worked with accessibility experts at Sun Microsystems and learned how deep the problem goes. A label is the easy part. Real accessibility needs roles, values, ranges, actions, traversal order, live announcements, collections, focus, platform conventions, and a way to test all of it. That complexity is why full Codename One accessibility support sat dormant for a decade. We eventually added setAccessibilityText() . It was useful, but it was the poor man's version. PR #5363 replaces that single-label model with a portable semantics tree we can be proud of. Lightweight UI needs a second tree Codename One paints lightweight components into its own native surface. VoiceOver cannot inspect a Button as a UIKit button because there is no UIKit button there. TalkBack cannot walk an Android View hierarchy because most of the painted controls are not Android views. The new accessibility manager builds an immutable virtual tree beside the visual component tree. Standard controls infer their semantics. Custom controls can replace or extend them. Each port exposes that virtual tree through the platform accessibility API. The visual and semantic hierarchies can differ. A card made from five labels might need to read as one item. A chart may paint 200 points from one component, but expose each meaningful point as a virtual child. A renderer-backed list can expose stable rows even though those rows are not component instances. Standard components work without annotations Buttons, checkboxes, radio buttons, sliders, text fields, lists, tables, tabs, labels, dialogs, and containers infer their normal roles, values, states, and

Widget support was one of the earliest Codename One requests. We dismissed it for years because a widget must render while the application UI is not running. A normal Codename One Component needs the application renderer, event dispatch thread, and live object graph. A home-screen widget gets none of those. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . The missing piece had been under our nose for a decade. Steve added background processes so an app could refresh data without showing its UI. That solves the update side. The rendering side becomes possible once the widget is data rather than a live component. PR #5365 turns that observation into com.codename1.surfaces , one API for home-screen widgets, Live Activities, Dynamic Island, Android ongoing notifications, and desktop floating widgets. The dead-process rule An external surface is a piece of application state that the operating system can render outside the app. The app publishes a serializable layout and a timeline of state maps. The platform persists that data, then renders it with its own surface technology. You cannot attach a Java listener to a widget. There may be no Java process to invoke. You assign a string action ID instead. A tap launches the app and delivers that action after startup. The simulator implements the same model. Open Widgets > Widgets Preview to inspect every registered kind, move through its timeline, change size and appearance, and click actions without creating a device build. Widget kinds exist at build time iOS and Android compile widget galleries into the native application. The kinds must therefore be known during the build. Add a surfaces.json resource: { "liveActivities" : true , "kinds" : [ { "id" : "delivery_status" , "name" : "Delivery" , "description" : "Track your order" , "iosFamilies" : [ "systemSmall" , "systemMedium" ] } ] }

Codename One Settings used to be a screen inside the old GUI Builder jar. It edited project properties, managed accounts, opened signing workflows, monitored builds, installed extensions, and accumulated every job that did not have a better home. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . PR #5359 replaces it with a standalone Codename One desktop application. It does fewer things, which is the point. One command, one project Run the new tool from a Codename One Maven project: mvn cn1:settings The Maven plugin resolves the com.codenameone:codenameone-settings artifact, launches it against the current project, and writes changes back to that project's codenameone_settings.properties and Maven configuration. The tool has its own release lifecycle instead of borrowing the GUI Builder's jar and version. This is the new Basic screen. It keeps the properties that belong to the source project: display name, package name, version, main class, icon, and related build choices. Build hints are searchable project data Build hints used to feel like an untyped text file with a dialog in front of it. The new editor preserves direct key-value control, but adds descriptions, known value types, filtering, and a focused editing flow. Nothing prevents you from editing the property file by hand. The Settings tool is useful when you do not remember whether the current spelling is ios.themeMode , and.themeMode , or a platform-specific signing key. It also keeps project values visible without mixing them with account state from the cloud. For example, selecting the modern native themes still produces ordinary project settings: nativeTheme = modern ios.themeMode = modern and.themeMode = modern The file remains the source of truth. The UI is an editor, not a second configuration system. Extensions keep compatibility warnings The Extensions screen

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. I...

An iOS or Android update can change a screen you shipped without you changing a line of code. If your app builds its UI from UIKit, SwiftUI, Compose, or Material widgets, Apple or Google owns those widget implementations. Codename One does something different. It statically links our lightweight component implementation into your native app. The UI you test is the UI your users keep after the next OS update. An update can still break a platform API or permission contract, but it cannot swap our button implementation for a new one. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . Lightweight does not mean a Java paint loop limping behind the platform. On iOS, components paint through our Metal pipeline. The moving Liquid Glass tab lens in this post is a Metal shader on the frame's existing command buffer, with no transfer of pixels back to the CPU. At the same time, last week's ParparVM work brought our ahead-of-time VM to geomean parity with warmed Java 25 across ten benchmarks. Six finished at or ahead of HotSpot. The tradeoff is that our UI does not inherit Apple's or Google's latest redesign for free. We have to study it, reproduce the parts that make sense, and test the result. That is work we take on so you can work on your app instead of working for the Apple and Google design teams. You decide when your app adopts a new look. The OS does not decide for you on upgrade day. The ParparVM and theme-fidelity branches ran in parallel. We wanted them in the same release, but each became too large to merge together safely. The fidelity work took longer. PR #5274 alone reports 53,000 additions across 1,147 changed files. Generated access registries, resources, screenshots, and native goldens account for much of that number, but the scale is still real. Five follow-up PRs fixed what the first pass exposed. Owning the component sta

In the age of "Cloud Everything," our most sensitive data—our heartbeat, our sleep cycles, our stress levels—often ends up on a server somewhere in Northern Virginia. But what if we could keep that data where it belongs? On your device. Today, we're diving deep into Edge AI and On-device LLMs . We will build a privacy-centric health coach that uses MLX-Swift to run Llama-3 directly on your iPhone's Apple Silicon. We’ll be pulling real-time Heart Rate Variability (HRV) data from the HealthKit API and generating semantic health summaries without a single byte ever leaving your phone. 🚀 Why Edge AI? 🛡️ When dealing with Private AI and sensitive medical metrics, the "Cloud-First" approach is a liability. By leveraging MLX-Swift and the Unified Memory Architecture of the A17 Pro/A18 chips, we achieve: Zero Latency : No round-trip to a server. Total Privacy : Your data stays in the Secure Enclave. Offline Capability : Health insights in the middle of the woods? Yes. The Architecture 🏗️ The data flow is simple but powerful. We fetch raw samples from HealthKit, preprocess them into a prompt-friendly format, and feed them into a quantized Llama-3 model managed by the MLX framework. graph TD A[iPhone HealthKit Store] -->|Fetch HRV Samples| B(Swift Data Controller) B -->|Normalize & Format| C{MLX-Swift Engine} D[Llama-3-8B-4bit Model] -->|Load Weights| C C -->|Local Inference| E[Neural Engine / GPU] E -->|Semantic Summary| F[SwiftUI Dashboard] F -->|User Feedback| A Prerequisites 🛠️ To follow this advanced tutorial, you'll need: Xcode 15.4+ and a physical iPhone (iPhone 15 Pro or newer recommended for 8GB+ RAM). MLX-Swift : Apple's framework for machine learning on Apple Silicon. Llama-3-8B (4-bit quantized) : To fit within the iOS memory footprint. HealthKit Permissions : Configured in your Info.plist . Step 1: Accessing HealthKit Data 💓 First, we need to grab that juicy HRV data. Heart Rate Variability is a key indicator of autonomic nervous system stress. import HealthKit c