标签：#iOS

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

If you ship a React Native / Expo app to the App Store, you know the ritual. Open the Apple Developer portal, create a bundle identifier, tick the capability checkboxes, generate a provisioning profile, pick the right certificate. Then hop over to the Expo dashboard, create the EAS app, wire up credentials, add your environment variables one screen at a time. It works, until you have to do it again for a second app, or a second environment, or a teammate needs to know why a capability is enabled. None of it is written down. It drifts. And the usual mobile tooling doesn't help much here: fastlane and the EAS CLI are great, but they're imperative — scripts that do things — not a declarative description of what your release setup should be . That's the gap these two providers fill: elevenode/appstore — App Store Connect: bundle identifiers, provisioning profiles, certificates. elevenode/expo — Expo Application Services (EAS): apps, credentials, environment variables, update channels. Both are open source (Apache 2.0) and published on the Terraform Registry. Let's use them together to describe a mobile app's release setup as code. What you'll need Terraform (or OpenTofu) An App Store Connect API key (Users and Access → Integrations → App Store Connect API): the key, its key ID, and your issuer ID An Expo access token (expo.dev → account settings → Access Tokens) and your Expo account name Export the credentials as environment variables so nothing sensitive lands in your config: export APPSTORE_KEY = " $( cat AuthKey_XXXX.p8 ) " export APPSTORE_KEY_ID = "XXXXXXXXXX" export APPSTORE_KEY_ISSUER_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" export EXPO_TOKEN = "your-expo-access-token" export EXPO_ACCOUNT_NAME = "your-account-name" Wiring up both providers terraform { required_providers { appstore = { source = "elevenode/appstore" } expo = { source = "elevenode/expo" } } } # Reads APPSTORE_KEY / APPSTORE_KEY_ID / APPSTORE_KEY_ISSUER_ID from the env. provider "appstore" {} # Re

I cranked Apple’s iOS 27 beta to maximum transparency on my iPhone and enjoyed every warped second.

Code found in an iOS 27 beta would allow Apple to put a financed iPhone in "Restricted Mode" if it detects any missed payments, 9to5Mac reports. The finding follows a story from Bloomberg earlier this week claiming Apple is preparing to launch a new "Apple Upgrade" financing program for leasing new devices. iPhones in "Restricted […]

A mobile user taps a button. Nothing opens. There is no validation message, exception, or visible loading state. The control simply appears dead. These bugs are frustrating because the visible symptom is tiny while the real interaction crosses several technical boundaries. I recently investigated this kind of failure in a Blazor Hybrid image workflow. The feature behaved sensibly in a desktop browser, but the same interaction did not reliably open the photo picker inside an iOS WebView. The useful lesson was broader than the eventual CSS change: A native capability launched from hybrid web UI is a cross-layer contract, not a single component event. To make the interaction dependable, the browser gesture, responsive dialog, native application metadata, and automated tests all had to agree. The visible button was not the real control Styled file-upload controls commonly hide the browser's native file input. A label or custom button receives the click and forwards it to the hidden input. That pattern can work well on desktop browsers. It provides visual freedom while retaining a native file-selection control underneath. The implementation I examined had taken the hiding quite far: the real input was clipped to a tiny area, while a separate visible element acted as its proxy. On desktop, the browser carried the user action through that indirection. Inside the iOS WebView, the picker did not open. This matters because browsers deliberately protect privileged actions. File pickers, cameras, pop-ups, clipboards, and media playback often require a trusted user activation. The further the real privileged element is removed from the original tap, the more likely platform differences become visible. The fix was conceptually simple: make the transparent file input span the visible button. The control still looks custom, but the user's tap now lands directly on the input that owns the privileged action. The input is visually transparent, not functionally absent. One repaired lay

I'm the developer of DeviceShelf, a local-first network scanner for desktop, mobile and a headless server edition. Until this week the iOS app only existed on TestFlight. Apple has now approved version 1.3.0, so for the first time you can get it straight from the App Store: DeviceShelf on the App Store . What the app does on a phone The iOS app is not a companion viewer. It runs the same scanning engine as the desktop version: it scans the network you're on, identifies devices (vendor, type, OS fingerprint), shows open ports per device, builds a security report, and raises presence alerts when devices appear or drop off. You can export and share results from the phone. The multicast entitlement iOS restricts multicast traffic for ordinary apps, and SSDP/UPnP discovery depends on it. Apple grants the multicast entitlement on request, and DeviceShelf's App Store build has it. In practice, UPnP/SSDP devices show up in scans on the phone the same way they do on desktop. Licensing The download is free and comes with a trial. Full features unlock in one of two ways: activate a DeviceShelf license, which covers desktop, mobile and the server edition with a single purchase, or use the in-app purchase upgrade on iOS. Pricing is on the website if you want the details. Local-first, on mobile too Scans stay on the device. There is no cloud account, and the AI-assisted device identification is bring-your-own-key; no key is bundled or required. The app is still young, and a phone is an unforgiving place for a network scanner. If it mislabels a device on your network or misses one entirely, I'd genuinely like to hear about it. Website: deviceshelf.app

Okay. This one is going to feel weird at first. I'm going to warn you in advance so you don't think...

The de-extinction startup is looking to double or triple its previous valuation, according to the report.

Adobe's Project Indigo can now remove all kinds of backgrounds from photos you snap using the app

"Something's coming. Something we may not be able to deter."

A helpful comment on my EXIF test suggested using a metadata scrubber. That is useful for ordinary still images, but a mobile upload contract must define every asset it sends. An iOS Live Photo can include both a photo resource and a paired video resource. The failure case is simple: the JPEG derivative has no GPS EXIF, while metadata or an original file associated with the paired video survives in the upload or retry path. Build the resource inventory first: let resources = PHAssetResource . assetResources ( for : asset ) for resource in resources { print ( resource . type , resource . originalFilename ) } Then make privacy assertions per output, not per UI selection: Artifact Required check still derivative no EXIF GPS/location fields paired video derivative no location metadata upload manifest only derived filenames retry queue no path to original resources temporary directory deleted after success or cancellation My lifecycle test would start an upload, force the app into the background after the still image is prepared, kill it while the paired video is processing, and relaunch. Recovery must either regenerate both safe derivatives or delete the incomplete pair. It must never mix a scrubbed still with an original video. Apple’s PHAssetResource API exposes the resources associated with a Photos asset. That enumeration should become evidence in the test: fail when an unexpected resource type is present rather than silently uploading it. Also verify what reaches the server. Device-side inspection alone misses multipart manifests, queued originals, and server-generated previews. Download the stored pair in a test environment and run the same metadata assertions again. A “remove location” button needs a precise scope. For Live Photos, the user reasonably expects it to cover the complete paired asset and every retry copy—not just the JPEG they can see.

A consumer health app isn't one product. It's eleven products stitched together into a single...

To learn how to analyze an error, we are going to use the error below as an example: nx run mobile : android ✔ 7 / 7 dependent project tasks succeeded [ 6 read from cache ] Hint : you can run the command with -- verbose to see the full dependent project outputs ————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————— > nx run mobile : android > npx expo run : android › Opening emulator Medium_Phone › Building app ... Starting a Gradle Daemon ( subsequent builds will be faster ) Configuration on demand is an incubating feature . > Configure project : [ ExpoRootProject ] Using the following versions : - buildTools : 36.0 . 0 - minSdk : 24 - compileSdk : 36 - targetSdk : 36 - ndk : 27.1 . 12297006 - kotlin : 2.1 . 20 - ksp : 2.1 . 20 - 2.0 . 1 > Configure project : app ℹ️ Applying gradle plugin ' expo-max-sdk-override-plugin ' [ expo - max - sdk - override - plugin ] This plugin will find all permissions declared with `android:maxSdkVersion` . If there exists a declaration with the `android:maxSdkVer sion` annotation and another one without , the plugin will remove the annotation from the final merged manifest . In order to see a log with the changes run a clean build of the app . ℹ️ Applying gradle plugin ' expo-dev-launcher-gradle-plugin ' > Configure project : react - native - firebase_app : react - native - firebase_app package . json found at / home / user / projects / my - app / node_modules / @ react - native - firebase / app / package . json : react - native - firebase_app : firebase . bom using default value : 34.10 . 0 dencies of : app : debugRuntimeClasspath > : react - native - firebas : react - native - firebase_app : play . play - services - auth using default value : 21.5 . 0 : react - native - firebase_app package . json found at / home / user / projects / my - app / node_modules / @ react - native - firebase / app / package . json : react - native - firebase_app : version set from

If you've ever localized an iOS or macOS app, you know the drill: you've got a .plist file full of UI strings sitting in Base.lproj , and now you need the same file in fr.lproj , th.lproj , de.lproj ... and so on for every language you support. You can pay for a translation service, hand it to a freelancer, or sit there manually retyping strings into fifteen copies of the same file. I didn't want to do any of those things, so I spent a day building pListTranslatorApp — a small SwiftUI macOS app that opens an Xcode plist, finds the string values you want translated, batch-translates them using Apple's built-in Translation framework, and writes out a ready-to-use localized plist. It's free, it runs entirely on-device, and it's now sitting on GitHub for anyone who wants it. The constraint that shaped the whole thing I'm developing on a MacBook Air with a 256GB SSD and 8GB of RAM — not a lot of headroom. That ruled out a couple of obvious approaches: Cloud translation APIs (DeepL, Google Cloud Translate, etc.) work well, but even a generous free tier means an external dependency, an API key to manage, and a network round-trip for something that's ultimately just short UI strings. Downloading a pile of on-device language models "just in case" eats real disk space fast — Apple's Translation framework models are shared system-wide across apps, which helps, but they still add up if you're not paying attention. So the app leans entirely on Apple's Translation framework , downloading exactly one language pack at a time, on demand, and lets you delete it once you're done with that language. What it actually does Open a plist. Pick any Xcode .plist via a standard file importer. Choose which keys to translate. Originally I hardcoded it to look for a key called itemTitle , but that's obviously too narrow for anyone else's project — so it's now a comma-separated text field. Type itemTitle, title, label and it'll pick up all of them, anywhere in the plist's nested dictionaries and

What if you could take an existing class and say "I want everything this already does, plus a few...

Part 2 — Search, palette, and settings Level: Intermediate · Time: ~35 minutes · Builds on: Part 1 — Contacts app Part 1 got you shipping. This one gets you productive . We'll take the Contacts app and give it the ergonomics real users expect: an adaptive sidebar that becomes a tab bar on iPhone, a command palette on ⌘K, honest loading states while data comes in, and a proper settings screen. Zero #if os guards. Zero re-rolled controls. What we're adding An adaptive shell — DFSidebar on regular width, DFTabBar on compact. A search field at the top of the list, filtering as you type. A ⌘K command palette exposing every action in the app. Skeleton loaders for a simulated slow fetch. A settings screen — notifications toggle, density picker, sync-interval slider, pinned-since date picker, beta-features checkbox. Per-component token overrides on the settings screen, without forking the theme. 1. Shell: sidebar on wide, tab bar on narrow The routing decision — sidebar vs tab bar — should be data, not a view hierarchy. Enumerate your sections once, then feed the two components the shapes they want. API note. DFSidebar uses Binding<String?> and is just the sidebar view — you compose the detail pane yourself (naturally via NavigationSplitView ). DFTabBar uses Binding<String> (non-optional) and does take a content builder that receives the selected ID. Both use plain String IDs, so we keep a simple Section enum and pass rawValue at the boundary. enum Section : String , CaseIterable , Identifiable , Hashable { case contacts , favorites , archive , settings var id : String { rawValue } var label : String { switch self { case . contacts : "Contacts" case . favorites : "Favorites" case . archive : "Archive" case . settings : "Settings" } } var icon : String { switch self { case . contacts : "person.2.fill" case . favorites : "star.fill" case . archive : "archivebox.fill" case . settings : "gear" } } static func from ( _ id : String ?) -> Section { id . flatMap ( Section . init (

Okay so. We need to talk about classes. If you've been following along with this series, you're...

Union wants to halt a "perpetual cycle" of layoffs, get back to contract bargaining.

If you've searched the App Store for a reliable third-party QWERTY keyboard on iOS, you know how that ends. Some are abandoned. Some are ad-riddled. Some feel like they were ported from Android and never touched again. The good ones are the ones that don't ship features so much as they don't crash. The system keyboard is fine. It's fine because Apple has been iterating on it for fifteen years. Nobody else has. Third-party keyboards on iOS are a graveyard. I'm building one that isn't. It's called Diction. Most people know it as a voice keyboard, and that's what I lead with, but under the hood it's a serious low-level QWERTY project too. This post is about that half of it, because that's the half nobody talks about. Why third-party QWERTY on iOS is a graveyard Building a good keyboard extension on iOS is hard. There's a strict memory ceiling. There's a permission dance the user has to opt into. There's no keychain access, no meaningful background work, and the extension can be killed the moment iOS decides it needs the RAM. Most keyboard makers ship a first version to check the box, then abandon it once they see how much work maintaining it takes. The result is what you see on the App Store today. Every third-party keyboard I've tried on iOS fails on at least one of these: Speed. You type a letter, the letter arrives. That's it. If there's a hitch you can feel, the keyboard is broken. Half the ones I've tried have a visible delay on every keystroke. Predictability. If you correct the same word back three times, that word should be yours. The keyboard should stop fighting you. Most never do. You fight the same wrong correction for a year. Recovery. iOS keyboard extensions are memory-constrained. Bad ones freeze under pressure. When you rapid-switch between apps, half the third-party keyboards on the store will lock up until you kill and reopen the host app. Autocorrect that isn't from 2014. Fix the obvious typos. Split words that ran together. Complete contractions. Ge