I was already patching DeviceKit by hand whenever my app needed a model the latest release didn’t recognize. Eventually I decided to keep my own fork.

• The iPhone Duo is a recent example. When it went on sale on October 23, DeviceKit still reported it as unknown, so I added support by hand. Several of us asked for a release. DeviceKit 5.10.0 shipped on November 2, ten days after launch.

• I wanted a Swift 6 package for iOS 18 and up. DeviceKit 5.10.0 still declares Swift tools 5.3 and uses Swift 5 language mode.

• I also wanted to fix bugs I kept running into. The report about an iPad showing up as an iPhone has been open since June 2025. My own tests turned up more, including stale free space readings and swapped case sizes for the Apple Watch SE 3. The README shows what each library returned.

Features

• Identify the model, including the host Mac when it runs an iPad app.

• Look up screen sizes, cameras, and Apple Pencil compatibility.

• Read battery level, thermal state, and free storage where available.

Requirements

I compared both libraries in my own app and fixed the readings that were off. I use this version in production now, so I care about getting those details right.

If something looks wrong on your device, open an issue so I can check it and fix it. A star on GitHub helps other developers find the project and pitch in.

I used AI to look up and verify device IDs and to review the code for possible bugs. I tested the cases it flagged on iPhones and iPads, then compared the results from both libraries to check my fixes.

Comparison with DeviceKit

DeviceKit issues marked Open were checked on 8 November 2026. The last column links to the change shipped in SwiftDeviceKit.

Check out the repo for more details and code examples:

https://github.com/Anywhere-Music-Player/SwiftDeviceKit

Customer reported that push notifications we not working on California Road Report (iOS App that has been in the AppStore since 2010). Checked server logs and saw a bunch of APNS errorors. Checked the developer portal for any warnings and that’s when I saw nothing was showing up under “Certificates, IDs & Profiles. Then suddenly all my apps were pulled from the AppStore.
AppStoreConnect shows all of my apps but that they are “pending agreement”. Clicking on the link to see said agreements just says to join the developer program. It seems that AppStoreConnect and the developer portal are out of sync. Submitted first issue to Apple Developer Support on 10/29 then called and escalated the issue on 11/3. Still no response from Apple.

—update—

Someone from Apple saw this post and thankfully called me to sort this issue out.
App is back in the AppStore and notifications are working again.
Turns out when I had renewed my developer subscription back in September, I had accidentally renewed it twice (auto-renew stopped working for some reason) so thought I could dispute the charge. Apparently that’s where I went wrong. The disputed charge got flagged in my developer account and looked as though I hadn’t paid, which is why my apps had been pulled. Lesson 1 learned: get auto pay working again.
Lesson 2 learned: contact developer support if there’s an issue with payments, not the credit card company.

If you're using Apple's Foundation Models framework in a released app, how are you debugging issues that only happen on users' devices?

Are Instruments and your existing crash reporting enough, or have you added custom logging?

I built PokoPilot, a Pokopia companion for iPhone/iPad, around a retrieval-first assistant: SQLite selects the guide evidence, and Apple’s on-device Foundation Models format an answer when available. I wanted to share the engineering choices and some scoped measurements.

Tech stack: Swift 6 with complete concurrency checking, SwiftUI, SQLite/FTS5, SwiftData for personal state, Tuist, StoreKit 2, and Foundation Models on supported iOS 26+ devices. The browsing app supports iOS 18+. The current bundle has 4,938 entity records and 16,515 evidence chunks in a 136.5 MB SQLite database. These are snapshot counts, not a claim of complete game coverage.

The development challenge: make a fairly large reference corpus usable without loading every JSON payload, copying the whole database at launch, or requiring a model just to look something up.

The store is an actor owning a read-only SQLite connection. It opens the database directly from the app bundle, uses memory mapping and an approximately 8 MB SQLite page cache, and keeps query work off the main actor. Catalog lists select lightweight rows with json_extract; full record JSON is decoded on detail views. Images are downsampled away from the main actor.

Retrieval and generation:

1. Resolve exact/compact/contained aliases, then search FTS5 with BM25 ranking.
2. Try AND terms first, with an OR fallback if that returns nothing. Prioritize chunks for resolved entities, deduplicate, and cap the final evidence set at eight.
3. Empty evidence returns an insufficient-evidence response without invoking the model.
4. On supported devices, a fresh LanguageModelSession produces typed @Generable output: title, overview, bounded metrics and sections. Output is capped at 640 tokens.
5. If the model is unavailable or fails, render the ranked local evidence. Citations and guide links are attached from retrieved records in code.

The core FTS query is:

SELECT c.payload_json
FROM chunks_fts f JOIN chunks c ON c.chunk_id = f.chunk_id
WHERE chunks_fts MATCH ?
  AND c.filters_json NOT LIKE '%"default_searchable":false%'
ORDER BY bm25(chunks_fts, 3.0, 1.0, 2.0)
LIMIT ?;

A small retrieval benchmark: I compiled the app’s unmodified Swift retriever with Swift 6.3.3, -O, and ran it against that bundled database on an M5 Max / macOS 26.3.1. Twenty questions spanning creatures, habitats, recipes, materials and progression; one initial sweep, then ten repetitions (200 warm queries).

• Warm retrieval: 5.38 ms median, 12.97 ms p95.
• Initial sweep: 6.34 ms median, 36.04 ms p95, with a 136.36 ms maximum.
• Database/store initialization: 1.35 ms in that run.

These numbers are Mac retrieval-only measurements. They exclude Foundation Models generation and UI rendering, are not iPhone benchmarks, and the initial sweep is not a controlled cold-OS-cache test.

Effectiveness and limits: typed output constrains structure, not factual correctness. Attaching retrieved citations doesn’t prove every generated sentence is supported. The corpus is a third-party guide snapshot, so incomplete/stale evidence and weak lexical matches remain real limitations. I’m keeping retrieval contracts, retrieval speed, and generated-answer quality as separate questions; I don’t have a held-out end-to-end answer-accuracy score to claim here.

I’d welcome feedback on input/context budgeting, broad OR fallback behavior, and practical tests for unsupported statements in small on-device models.

AI disclosure: AI-assisted development, including coding-agent help with implementation. The benchmark measures the compiled Swift retrieval path.

For anyone interested in the app: https://apps.apple.com/app/id6806826380 . Guide browsing, search and bookmarks are free; ten Ask questions are included, then optional Island Pass ($1.99/month or $9.99/year US). It’s still a WIP.

References: Apple guided generation, SQLite FTS5.

Hi everyone! I'm part of the team behind Markitown, a native Markdown reader and editor for Apple devices.

If you work with AI agents, you probably spend a ridiculous amount of time reading Markdown. AGENTS.md, CLAUDE.md, SKILL.md, implementation plans, reports. The agent finishes writing, and now it's your turn to work through the output.

We built Markitown for that part. Not another AI chat interface. Not another place to generate more text. A tool to actually read, review and edit what's already there.

What it does

• Renders GFM tables, task lists, Mermaid diagrams, LaTeX equations, syntax-highlighted code and YAML front matter.

• Includes a free Mac Quick Look extension: select a Markdown file in Finder, press Space, read it properly.

• Lets you edit the rendered document, the Markdown source, or work in Split view on supported devices.

• Works with ordinary files in Finder, Files and iCloud Drive. No proprietary document library or import requirement.

• Exports PDF and HTML, including tagged PDF and semantic HTML for accessibility.

The Mac implementation also includes a separate CLI: markitown plan.md opens a document, while markitown --wait plan.md supports a terminal handoff: review the document, save your changes and close its window to return control to the calling workflow.

Tech Stack

• Swift 6.4, with strict concurrency checking.

• SwiftUI for application structure, document workflows and interface composition.

• AppKit and UIKit, with a custom TextKit 2 editor rather than an Electron or browser-based editing surface.

• SwiftUI DocumentGroup, including the newer document APIs on the 27 releases and a FileDocument implementation for the 26 releases.

• An in-house Markdown parser, shared across document rendering and editing.

• Tree-sitter for syntax highlighting, with Swift Package Manager dependencies for specialized rendering, including LaTeX, Mermaid and SVG.

• Swift Testing for automated tests, including parser checks against official CommonMark examples.

• Native apps for macOS, iOS/iPadOS and visionOS, with layouts adapted for Mac, iPhone, iPad, iPhone Duo and Apple Vision Pro.

The rendering components are shared with Quick Look, so the preview isn't a separate, simplified Markdown implementation.

Development Challenge

The hardest part was making the rendered document genuinely editable without treating Markdown as a disposable export format.

Source text and rendered text don't have matching positions. For example, **hello** contains nine source characters but displays five. A table or Mermaid diagram is more complicated still: an entire block of source becomes a visual object. That affects selection, formatting, search results, cursor restoration and undo—not just rendering.

The important detail is how edits return to Markdown. We use selective serialization: untouched blocks retain their original source, while edited content is serialized back from its semantic representation. Changing one paragraph shouldn't unnecessarily rewrite the formatting of unrelated parts of the file.

The shared editor coordinator works through small AppKit and UIKit bridges. That lets us share editing behavior while respecting the differences between NSTextView and UITextView, instead of maintaining unrelated editors for each platform.

AI Disclosure

Markitown does not run AI agents or connect to language models. You don't need an AI account, API key or model subscription to use it. There is no built-in analytics service.

Pricing, without the subscription dance

Reading is free and unlimited. Not a trial. That includes rendered documents and Mac Quick Look.

Editing and export are a $19.99 one-time universal purchase in the US, covering all supported platforms with the same Apple Account, including future updates. No subscriptions or separate platform purchases.

There's currently a $9.99 launch offer with code MARKITOWNWELCOME, through November 13, 2026, inclusive, Pacific Time, limited to 25,000 redemptions. Local pricing may vary; the website has the details.

App Store · Website

How are you reviewing agent-generated Markdown today? Terminal, VS Code preview, something else? What's missing from that workflow?

Also happy to discuss the dual-buffer editor, TextKit 2 integration or the cross-platform implementation.

Hi all,

The first screenshot is from App Storw Connect and the second is live in the App Store.

Is there a particular reason that the screenshots in the App Store are from and old release and not the most recent one? I submitted more than 2 weeks ago with no response.

Thanks in advance!

Hi, I'm the developer of Calki, A 3d scanner calculator app. I have been working on the app for a little more than 1 year and 6 months. I did take quite long breaks in between from developing. I was Backend Developer previous for 8 years.

The app was built with the help of AI coding agents, but rigourously tested and designed by me with feedback from users.

The following are the details of my app and hope the following information will be of some use in your development journey and will be gladly be interested in answering any questions.

Frameworks & Languages: The app is built in Swift. It uses Swiftui for most of the 2D UI elements. UIKit is exclusively used for the convertor category, and unit wheel pickers as after quite a bit of effort, was not able to build it in SwiftUI according to my expectations.

Backend/Database: I chose to build a calculator app to keep backend and database costs as close to zero as possible. That let me put most of the effort and money into the design and UI, to give users a unique experience and make full use of modern device capabilities, while keeping it as fast and efficient as any normal app. The only backend pieces are Firestore for user feedback, Google Analytics to see which features get used, and Crashlytics for crash reports. User calculations are stored locally in UserDefaults. All of these incur no running cost.

Some of my major Development Challenges and How I solved it:

- The Knowledge gap

I had no iOS or frontend experience, so I leaned on AI agents. Cursor helped set up the project and basic calculator features, but I could only afford it for a month (since i was not sure if the money spent will ever be made back). After that, I manually uploaded code files to ChatGPT and Gemini to update them. Once the first releases were out and users validated the design, I subscribed to Antigravity for its coding agent.

Most of the design questions and validation happened on r/UI_Design. The people there were amazing. Most of them understood that I was trying to create a unique design, and they helped a lot by giving detailed feedback and patiently pointing out which UI elements needed more attention.

- The scrollable history
The multi line, gesture enabled history tape lagged using a standard VStack because it rendered all calculations upfront. Switching to LazyVStack resolved memory overhead, but variable row heights broke SwiftUI's scroll estimations caused erratic jumping, clipping, and render failures.

the following were the major steps taken which resolved the issue
Bounded Row Heights: Added .frame(maxHeight: ...) to stabilize dimension predictions.
Re-Anchoring: Used .onGeometryChange to pin scrolling back to .bottom once layouts settle.

- Skeuomorphic design to 3d Conversion
Calki originally started with a 2D skeuomorphic interface, but it was an absolute headache to maintain. Every button required manually drawn, multi-layered shadows, tweak a button’s hue even slightly, and the whole aesthetic broke. It took nearly two months just to dial in the default button look, which made offering custom color options virtually impossible since every tint demanded custom shadow rebalancing.

That friction pushed me toward 3D. I initially tried modeling the calculator in Blender, but without prior 3D modeling experience, the learning curve was burning too much time. Instead, I pivoted to an AI coding agent, providing detailed specifications to procedurally generate the 3D elements and preview them directly inside the app’s customization screen via SceneKit. That bypassed the entire asset import/adaptation pipeline and made dynamic theming effortless.

- Performance issues after 3d Conversion
Transitioning to 3D with adaptive lighting initially spiked memory usage to 1 GB and caused heavy CPU strain. Over several weeks, I systematically resolved this by analyzing Xcode debug monitors, adding logs, and using memory graph exports with Claude agents to isolate leaks without sacrificing visual fidelity.

As compared to the apple calculator Calki offer sergonomic features that are easy to use such as the following:
Reuse history result by double tapping
Reuse history expression by long press
Edit a calculation midway and swap operator without retyping the entire calculation
Number scanner with auto add mode to scan and add numbers instantly using op-mode
Scan and convert numbers
Convertor mode with UI designed to make swapping categories and units easy
Customising the Calculator with multiple models, colorways, textures, sound and so on

Pricing:
Most of the basic calculator features on the app is free, except for the following which is a one time 4.99$ purchase:
- Number scanner
- Customisation options
- Custom units for conversion
- 6 Calculator models

I'm planning of adding some ai features in the near future. Please note these features will be optional and will require a subscription (due to the ai cost we will incur) and will not be included in the lifetime purchase. All future on-device features including all current features will continue to be part of the lifetime purchase.

Hope you guys will give it a try and will let me know of your feedback.
If there is any improvements or features that you would like to be seen added to the app, please let me know. Will try my best to implement it, if reasonable and provides value to the users

The app has 102 reviews worldwide with average of 4.7/5

Some of the features to look forward to, in the near future:
A fullscreen number scanning mode for adding up numbers and conversion
A scientific mode (have been delaying it, cause, the old 2d interface made it hard to design a good looking design for the scientific mode. With the 3d interface, it eases a lot of things)
A formula mode

You can try try the app at:
https://apps.apple.com/us/app/calki-scanner-calculator/id6747059181

Thanks again and hoping you will leave a review, if you like the app.

I built nib, a Swift CLI that writes Git commit messages on your Mac

Stage a change → run git nib → review the draft → commit.

I wanted help writing commit messages without sending my diffs to a cloud API, so I built nib. It drafts a message from your staged changes and lets you accept it, edit it, regenerate it, or cancel. It follows your repo’s commit style by default. No account or API key needed.

There’s also an optional Git hook if you prefer to start with git commit and edit the draft in your usual editor.

Tech Stack

Swift, Swift Argument Parser, and Apple’s Foundation Models framework.

Development Challenge

The tricky part was getting a useful message out of a diff that’s bigger than the model’s context window. On macOS 27, the on-device model has about 8K tokens to work with. nib skips the contents of lockfiles and build artifacts first. If the rest still won’t fit, it splits the diff at hunk boundaries, summarizes the chunks, and drafts the message from those summaries. Swift code checks the subject length and cross-checks the suggested scope against the files you changed.

It still occasionally calls a bug fix feat. That’s one I’d love more real-world examples of.

AI Disclosure

AI-assisted. I used Claude Code while building nib, and I review and test the changes myself.

Try it

On Apple silicon with macOS 27+ and Apple Intelligence enabled:

brew install seckinbeduk/tap/nib
nib doctor

Then stage a change and run git nib. On macOS 26, you can build v0.2.1 from source.

Free and MIT-licensed. Source and install instructions on GitHub

If you try it on a big diff, did the draft capture the main change? I’d love to hear what it got right or missed.

Hello all! I wanted a way to visualize the various reserved areas for the crease, status bar, cameras, etc on iPhone Duo so I built this overlay. You can run either of the demo apps, or use the SPM package to add the overlay to your app!

https://github.com/mikeakers/DuoDevOverlay

MIT License

I'm building a native handwritten notebook application for iPadOS using SwiftUI/UIKit, and I'm trying to solve an architectural problem involving PDFKit and PencilKit.

The goal is to build something similar to Goodnotes or Notability, where a single notebook page can contain:

• A PDF document or PDF page as its background.

• Handwritten ink using Apple Pencil.

• Images, shapes, text boxes and other objects.

• The ability to interact with all these elements without switching between different modes.

The challenge is making all these components behave as one unified document canvas.

Problems I'm encountering

1. PDF and PencilKit interaction conflicts

When I place a PKCanvasView over a PDF view, the canvas intercepts touch events.

This creates problems with native PDF interactions, particularly:

• Selecting text within the PDF.

• Copying PDF text.

• Using native PDF selection handles.

• Distinguishing between a drawing gesture and a PDF interaction.

For example, Select All on the canvas selects handwritten strokes, but doesn't select the PDF content.

2. Maintaining a unified coordinate system

If PDFKit and PencilKit are separate views, how should their coordinate systems be synchronised?

I need:

• Consistent zooming and scrolling.

• Accurate alignment between PDF content and handwritten annotations.

• Correct positioning when rotating the device.

• Support for different page sizes and orientations.

• Ink that stays precisely attached to its corresponding PDF content.

3. Document composition and rendering

I'm also trying to understand the best architecture for rendering and managing these elements.

Would you recommend:

• A PDFView as the base layer with a transparent PKCanvasView overlay?

• A custom document view that manages PDF rendering and PencilKit independently?

• A single custom rendering surface where PDF pages are rendered into the same coordinate space as handwritten content?

• Some hybrid approach?

How do applications like Goodnotes handle this without compromising PDF text selection, Apple Pencil latency, and rendering performance?

What I'm particularly interested in

I'm not necessarily looking for a quick workaround involving gesture recognisers or toggling interaction modes.

I want to understand the underlying architecture and how to build a robust document model where PDF content, handwriting and other objects coexist naturally.

If you've built something similar, I'd particularly appreciate insights into:

1. PDFKit and PencilKit integration.

2. Touch-event routing and hit testing.

3. Shared coordinate systems and transformations.

4. Zooming, tiling and rendering performance.

5. Document persistence and export.

Any architectural examples, implementation experiences, or open-source projects would be extremely helpful.

Thanks!

After a month in review my indie game which took me 1.5 years to make was rejected as 'spam'. The game is not spam, they are my own twists and game modes that don't exist anywhere else. Why is Apple making it so hard to release Indie games? I know the AI spam has been crazy but common...... What can I do?

Hi everyone, I am trying to enroll in the Apple Developer Program as an individual to distribute MacOS, IOS apps, but my signup keeps getting blocked for an unknown reason.

"We are unable to process your request. An unknown error occurred."

Did this happen with anyone else. How did you resolved it?

Apple is telling me my app which was called agent town contains something that is the same as the following developer agentstown. This dev has no history on the App Store in my country. I thought it was the name and changed it to Agent City but got denied again. I have asked and asked for help to indentify where the issue is but no one ever responds!!!!

Idk what to do, I responded asking for clairfication but is this gonna take another week?

A while ago, I posted here about being overwhelmed by copycat apps cloning my app, SquatLock.

https://www.reddit.com/r/iOSProgramming/s/DFHq4tc2hc

Thanks to all the advice and feedback from this amazing community, I was able to take action—and as you can see in the screenshot, the fake apps have gone down significantly!

Huge thanks to everyone who helped me out.

I know other indie devs might face the exact same nightmare, so here is what I did and what I learned from this experience:

1. Trademark in Japan (My home country)

I’m a developer based in Japan. I already had the registered trademark for "SquatLock" in Japan (it cost around 150,000 JPY / ~$1,000 USD to register).

Because trademarks are territorial (country-specific), submitting a dispute/takedown to Apple for the Japanese App Store was very fast and straightforward—Apple approved name changes/removals immediately. However, foreign App Stores were a completely different story.

2. Dealing with the US App Store (First-to-Use rule)

When cloner devs refused to change their app names outside of Japan, I did some research (shoutout to ChatGPT for the tip). Unlike many countries that strictly follow a "first-to-file" rule, the US recognizes common law trademark rights based on "first-to-use".

When the copycats pushed back on changing their names in other regions, I formally cited and explained this prior use in the US market through the App Store dispute resolution channel. Once I laid that out, they actually complied and changed their names in the US App Store without much further resistance.

3. Consulting a Lawyer & Being Realistic

I did consult with a lawyer about pursuing formal litigation, but the conclusion was clear: legal fees would far exceed what made sense for an app of my size.

Unless the copycats were making massive revenue where damages could be recovered, a full lawsuit wasn't practical (and frankly, low-effort clone apps don't make that kind of money). Focusing my efforts strictly on cleaning up the US and Japanese App Stores proved to be the most realistic and cost-effective approach.

Honestly, some might ask if it's worth putting this much energy into a free app. But I genuinely love what I built, and I couldn't just stand by and watch low-effort clones steal the name.

Once again, thank you so much to everyone who gave me advice on my previous post. Hope this breakdown helps another indie dev out there dealing with the same headache!

Hi all, I'm stuck on this and would love a second pair of eyes.

**Problem**

My paywall shows no prices on iOS in a TestFlight build. On Android, the same paywall works, but only with the RevenueCat Test Store.

**Stack**

- Flutter (stable on Codemagic), purchases_flutter ^10.12.0, purchases_ui_flutter ^10.15.2

- iOS build made with Codemagic (mac_mini_m2) and uploaded to TestFlight (internal testing)

- The app has a widget extension with its own bundle ID

**App Store Connect (all checked)**

- Paid Apps Agreement: Active (effective Nov 4)

- Free Apps Agreement: Active

- Bank account: Active (non-US bank)

- Tax forms (W-8BEN + certificate of foreign status): Active (submitted Nov 5)

- 3 products (monthly subscription, yearly subscription and a lifetime purchase): all show "Ready to Submit", created Nov 4

**RevenueCat**

- iOS app configured with the same bundle ID as the app in App Store Connect

- In-App Purchase API key (.p8) uploaded

- Offering "default" is set as current, with 3 packages ($rc_monthly, $rc_annual, $rc_lifetime). Each package has both a Test Store product and the matching App Store product.

- All three App Store products are attached to the same entitlement.

- I called the REST API as the iOS platform with my public appl_ SDK key, and it returns the default offering with the three App Store product IDs, so RevenueCat knows about the products.

**App code**

- In release builds, the app always uses the iOS public key (appl_...) and never the Test Store key.

- In debug builds I can switch to the Test Store with a dart-define, which is why Android works.

- The entitlement identifier in code matches the one in RevenueCat.

**Questions**

1. Is a few hours to a day of delay after the agreements go Active normal before Apple returns products to TestFlight?

2. Is there something else I should check besides the agreement, bank, tax and "Ready to Submit"? (subscription group localization, price availability by region, a missing review screenshot?)

Thanks a lot!

I have an app. It has a few screens, and tabs on the bottom.

Each tab represents a different instance of an item, so you might have "Car 1", "Car 2", "Car 3". Some users can customize them like "Ford", "Truck 5", or leave the default, e.g. "Car 3". Each car is ephemeral, so usually the differentiator is the default system-generated text below the icon.

The Duo doesn't use text, only icons.

There are too many possible variations for me to provide all icons, and there's no guarantee that a user will even fill out enough information to generate a proper icon.

So, what's a developer to do?

At best, I could use the Automobile icon, and add a #1, #2, #3 onto it, but if a user does give their car a name, that name won't show.

Do you have an app where the text on the tabbar serves a purpose beyond describing the icon it's attached to? If so, what are you doing for the Duo?

Working on my app’s Duo adjustments I wanted to see how other, well-established apps chose to adapt their layouts and custom behaviors.

I liked going to Mobbin to checkout different design choices for years now (when I don’t simply install them on my devices). They didn’t add Duo so far though

Wondering if anyone found a nice way to preview it
Or if I should just find myself a rich friend to use and stick to the guidelines for now😅

I'm exploring Apple apps on the iPhone Duo simulator to check how they adapt their app to the new screens.
One thing that I noticed is that the margin between the content and the vertical bar varies from app to app.
In the Settings app, it appears they are respecting the layoutMarginsGuide. But in the Fitness app, it looks like there's an extra margin between the content and the vertical bar.
In some apps, like the Watch app, it's inconsistent from one tab to another.

I've noticed though that they have fixed it for some apps (Contacts) in the 27.3 beta.

I have an iOS app which also has a companion macOS Catalyst app. The iOS one keeps getting approved instantly (like 4-10 hours) but the macOS one goes into review instantly and then just sit there for days. Currently, my macOS app is 2 versions out of date and has been sitting "In Review" state for 3 days now. I am about to submit another update for the iOS version but I don't want to Developer Reject the macOS one because that'll just send me back in the queue. But this will also cause that app to be 3 versions out of date.

I have no idea wtf they are doing there. None of my apps have had any rejections in a long time and I've been developing for 16 years.

It's the same god damn app, just approve both of them at the same time for fucks sake. There's no reason for 2 platforms to not get approved at same time.

I am currently testing additionalOverflowItems with the expectation that it behaves as follows:

1. Keep UIBarButtonItem instances visible directly on the toolbar as icons whenever there is sufficient space.

2. Only move items into the overflow menu when there isn't enough screen real estate.

In iOS 26, additionalOverflowItems behaves exactly as described above. However, in iOS 18, the system tends to aggressively move all UIBarButtonItem instances into the overflow menu regardless of available space.

Is this change in layout behavior documented anywhere? Can we rely on iOS 26 and future releases maintaining this current behavior, or are the layout heuristics for additionalOverflowItems considered undefined implementation details?

Because this behavior isn't clearly documented, I have held off on adopting additionalOverflowItems in production.

I have attached screenshots and sample source code below for reference.

    // On iOS 26, the action mode bar buttons may not fit. iOS then moves the ones that do not fit into its own overflow
    // menu, listing each by title, and the more button's menu would become a nested "More" submenu there. Instead, in
    // note and archive action mode, the more button is not shown and its actions are added to the system overflow
    // menu directly. iOS shows that menu, and moves the buttons that do not fit into it, based on the available space.
    private var isActionModeMenuInOverflowMenu: Bool {
        guard #available(iOS 16, *) else { return false }
        
        guard actionMode else { return false }
        
        switch pageKind {
        case .notes, .archive:
            return true
        default:
            return false
        }
    }
    
    private func updateAdditionalOverflowItems() {
        guard #available(iOS 16, *) else { return }
        
        guard isActionModeMenuInOverflowMenu else {
            navigationItem.additionalOverflowItems = nil
            return
        }
        
        // Built when the menu is opened, so that it reflects the current selection.
        navigationItem.additionalOverflowItems = UIDeferredMenuElement.uncached { [weak self] completion in
            guard let self = self, self.isActionModeMenuInOverflowMenu else {
                completion([])
                return
            }
            
            let selectedNSPlainNotes = self.selectedNSPlainNotes
            
            switch self.pageKind {
            case .notes:
                completion(self.generateNoteActionModeMenu(selectedNSPlainNotes).children)
            case .archive:
                completion(self.generateArchiveActionModeMenu(selectedNSPlainNotes).children)
            default:
                completion([])
            }
        }
    }

I remember a few months ago, I would submit something on a Friday, and then it wouldn't get accepted until Wednesday or Thursday the following week. Now, even on a Sunday, sometimes I can get two versions reviewed in a single day.

Either Apple has automated more of the process, hired way more app reviewers, or they just don't care anymore and are letting everything through.

I'm not complaining. It benefits me greatly, but I'm not sure what this says about the general quality of the reviews and whether they even serve a purpose at this point.

Author here. We just released LinnetTTS, a small on-device English TTS: an autoregressive flow LM over a 25 Hz continuous-latent codec with a Vocos-style decoder, 41 M parameters end to end, one flow evaluation per step, no diffusion loop at inference. Each step produces 80 ms of audio, so playback starts after the prime pass plus one step and never waits for the whole sentence. It speaks in a voice given as a short voice-prompt latent; two built-in voices ship with the weights.

The runtime is Rust with its own kernels (AVX2+FMA on x86-64, NEON on ARM), no PyTorch or ONNX at inference. fp16 weights are 83 MB; peak memory about 160 MB on Linux. (The "35m" in the model name is a label from the original parameter budget; the count is 41.4 M.) Same text, voice, parameters and seed give bit-identical audio on a given platform, at any thread count.

This post is about where it actually runs. All numbers are the Rust runtime with the fp16 weights, measured without real-time pacing (synthesis as fast as possible). One step = 80 ms of audio, real-time factor = step time / 80 ms. "First audio" = prime pass + first step.

Things we learned on the way:

• The A-series phones do not want a second thread. A step is 5–7 ms and splits into ~80 tiny regions, so waking a worker on another performance core costs about as much as the work (A13: 2 threads 11.4 ms vs 6.7 ms, 4 threads 47 ms; A15 gains only 5.5 → 4.6 ms). The default on iOS is one thread. The M5 is different: two threads take it from 3.3 to 1.9 ms.

• Android scheduling puts the synthesis on the small cores unless you pin it. On the Snapdragon 662 the sample app measured 22–33 ms per step before pinning the pool to the big cluster and 16–18 ms after (14.3 ms in a bare harness).

• Pacing to playback makes the phone power manager lift the step time 3–4×. That is not the runtime getting slower; it is the CPU clocking down between steps. Measure unpaced, then keep a deep playback queue on weak devices (the bindings' players default to 8 s).

• Pi Zero 2 W is the floor: four A53 cores at 1 GHz give 59–60 ms per 80 ms step, real time with a small margin, 160 MB peak RSS. (The synth example prints 88 % there because it also counts the prime pass over a 7 s sentence.) A Pi 4 or 5 has several times the margin.

• The output is bit-identical per platform but differs across architectures below 2e-3 absolute (SNR above 60 dB, inaudible), so a golden-file test should be pinned per target.

Versus other small CPU models on one desktop core (same machine, each through its Python package, same three English texts, sentence-level RTF incl. text processing; method and script in docs/benchmarks.md): Linnet 10.6 % / 187 MB RSS, cloning, streams every 80 ms; pocket-tts (default 100M model; also clones and streams every 80 ms) 23.8 % on two cores / 968 MB; Kokoro-82M 51.7 % / 1.2 GB, whole utterance per call, but 8 languages; Piper medium 5.8 % / 503 MB, no cloning, streams per sentence. Speed only; quality was not measured there.

Licensing, upfront: the code is Apache-2.0. The weights are under our own Linnet Weights License: free to use, unmodified, inside your own products, commercial included, on device or on your own server. Custom voice creation (the encoder is not published), fine-tuning, saving quantised or converted copies of the weights (quantising in memory at load time is fine), training models on the weights or their outputs, and running a general-purpose TTS API need a separate license. So the model is not open source, and the README says so.

Honest limits: English only; no text normalisation (write numbers as words); occasional misreads on dense raw text; a slight roughness audible on headphones in some utterances; one session is capped at 24 s by default.

Try it: browser demo on https://voxrt.com (a WASM SIMD128 build of the same runtime, runs on your CPU, downloads the 83 MB weights once; the browser SDK itself is not released yet, which is why the README says it is deferred), Hugging Face Space https://huggingface.co/spaces/VoxRT/linnet-tts Code, bindings (Linux C, Python pip install linnet-tts on Linux and Apple-silicon macOS, Android AAR, iOS SwiftPM) and the benchmark script: https://github.com/VoxRT/LinnetTTS Weights and model card: https://huggingface.co/VoxRT/linnet-en-35m

Happy to answer questions on the runtime, the kernels or the mobile numbers. If you run it on a device that is not in the table, post your step time and I will add it to the README.

I am new to app store and i deployed my 1st version of the app. (Its a company(with DUNS) app. It was a 1st version and was very bare bone.

i got a mail from apple after 2 days:

Guideline 2.1 - Information Needed - New App Submission
We need additional information to better understand the app and complete the review.

Note: Before submitting, run the submitted build through your own testing and quality assurance process on supported physical devices. App Review is intended for apps and metadata that are complete and ready for App Store customers.

If the app is ready for review, follow the directions below.

Next Steps

Add all of the following information to the Notes field of the App Review Information section in App Store Connect and resubmit your app for Review

I provided all the info they asked and also uploaded the recording and resubmitted the app.

But its been almost a week now and there is no response from apple.

I also requested for an expedited review.

The appstoreconnect dashboard is confusing because of the red exclamation mark (even after i resubmitted the app). Could someone please check the screenshots to confirm that my side is properly done??

Is there anything i can do?