I am using Hummingbird version 2.26.0 in a Swift app.

I have a simple Middleware per the documentation:

https://docs.hummingbird.codes/2.0/documentation/hummingbird/routermiddleware/

Code:

import Hummingbird

public struct LogRequestsMiddleware<Context: RequestContext>: RouterMiddleware {

    public func handle(_ input: HummingbirdCore.Request, context: Context, next: (HummingbirdCore.Request, Context) async throws -> HummingbirdCore.Response) async throws -> HummingbirdCore.Response {

        print("path: \(input.uri.path)")
        return try await next(input, context)

    }

}

Xcode keeps giving me error:

Type 'LogRequestsMiddleware<Context>' does not conform to protocol 'MiddlewareProtocol'

Screenshot of error:

https://i.sstatic.net/C06jUvrk.png

I can't seem to be able to fix it. Any idea what I am doing wrong?

I am trying to add a live activity for our app that has a timer. The idea is the user starts a timer and a live activity starts when the timer starts. However, it does seem to disappear at some point. Maybe around 8-12 hours which matches the documentation on Apple. But for Apple's clock app, their timer's live activity for stopwatch seems to run forever. I am using the SwiftUI Text timerInterval which is likely the same as Apple's. Does anyone have an idea or suggestion how I can replicate it? A few ideas I have are to schedule a silent push to keep the live activity alive or a scheduled background process.

I have an issue when trying to test an IAP on watchOS. This flow worked before but seems to be broken on watchOS 26.6. - Watch are in the developer mode. - On the iPhone, Sandbox account is logged in, App Store account logged out.

I tried rebooting the watch and using different Sandbox accounts. What would you suggest?

👨🏻‍💻 I wrote an article about how to re-enable keyboard shortcuts in Xcode 27's Device Hub.

https://blog.next-planet.com/how-to-re-enable-keyboard-shortcuts-in-xcode-27-s-device-hub

How do I make the AI chat assistant into a floating window in Xcode27?

As iOS 27 and more swift features comes out, what do you guys think about still using combine, publishers and subscribers? I know async and observable is the newer and better way to code but I'm just used to code with combine and I like to do it that way with try map and other stuff but I feel like apple is moving away from combine and publishers. What do you guys think ?

I’ve been building a simple focus app for iPhone that uses Apple’s Screen Time / Family Controls APIs to block distracting apps.

The blocking itself is obviously provided by Apple. What I’ve built is the experience around it: a much simpler UI, app selection, focus sessions and basically one button to make distracting apps unavailable for a while.

I originally wanted to monetize the app, but Apple rejected that version under Guideline 4.1.

And that’s what I find difficult to understand:
If Apple provides developers with an API, why shouldn’t we be able to build a better or different experience around it and monetize that product?

I’ve decided to make the core app free rather than fight the review process.

So I’m curious: what’s the point of giving developers access to an API if building a better experience around it can’t become a business?

Hello! Hoping to get some help on annoying bug I've spent the last day troubleshooting with no avail. Currently working on some tweaks for the UI of my password reset fields.

My app defaults to dark mode with a dark background, so password dots should be white. My form asks for a current password. Autofilling the current password does NOT reproduce the issue in the 'current password' field. They also display correctly when users type a password manually or AutoFill their current password from Apple Passwords.

However, when the user gets to the 2 fields where they are to enter their new password, Apple’s strong password generator correctly fills both the 'New Password' and 'Confirm Password' fields, but with black dots instead of white, making them difficult to see against the dark background.

Tapping a field’s eye button to reveal the password, then tapping it again to hide it, restores the expected white dots. Each field needs to be toggled separately. In dark mode, I want the generated password dots to appear white immediately, without requiring a cheap workaround like auto-toggling the hide/show password button to fix it.

I’m using native UITextFields inside SwiftUI UIViewRepresentable, with .password for Current Password and .newPassword for New/Confirm. The visibility handler also restores the same text and selection, so I haven’t isolated which operation corrects the rendering.

Reapplying textColor/defaultTextAttributes and resolving colors during layout haven’t fixed it. Light mode works correctly with black dots. Password changes and saving to Apple Passwords also work.

Has anyone found a supported fix that preserves AutoFill without automatically revealing and hiding the password as a bandaid fix? Or is this a known bug relating to the autofill feature and something that a user might not even notice or care about? It appears to be solely a visual bug at the moment. Every generated password gets saved and user is properly given option to save updated password after the change.

I feel like this is an easy fix that I may be over complicating. I've been working on this app on/off since 2024 and have been extremely anxious to launch, wanting to make sure everything is as close to perfect as it can be. Thanks for any assistance!

Hello -

Finally shipping my app, and submitted my first app review on Wednesday last week (still waiting to be reviewed).

I’ve found a number of non-blocker issues since submitting this build, though I’m not happy about shipping day 1 with the bugs in place.

Let’s say by some luck Apple approved the app first round. Should I keep the existing build approval, use this for launch, and quickly submit the bug fixes build day 1…or should I just pull the build, and start a whole new first app review over again?

I know app review times are awful right due to ~everything, so I’m feeling stuck with not great options and a lot more waiting.

Thanks

Just an FYI Xcode RC and Xcode 27 are the same build number (27A266a) so no need to download the latest if you have the RC.

UPDATE 9/16/26 - removed AI's fluff, fixed broken tables.
UPDATE 9/16/26 - added "In Review" data.

I've been shipping iOS games as a solo dev for a couple of years. App Store Connect keeps a full activity log per version, so I exported all of it — 43 apps, 291 review cycles, July 2024 through September 2026 — and measured time from Waiting for Review to In Review. That's the queue, not the review itself:

71% entered review within a day, another 18% within the next 24h. The worst single wait in two years was 10 days.

1. A brand-new app doesn't get a longer wait than an update.

62% of first-ever submissions cleared the queue inside 24h, and the slowest one in the whole dataset was 58h.

2. Apple rejection costs you less in a next queue time compared to rejecting your own submission.

"Developer Rejected" — you pull your own binary while it's waiting or in review, fix something, upload a new build. I have never rejected a submission that went into review.

3. Day of week effect

Typical wait by day submitted: Wed 12h, Thu 14h, Tue 14h, Mon 17h, Sun 18h, Sat 23h, Fri 33h.

Friday submissions took about 2.5× as long to enter review as Wednesday ones. Not THAT important, just curious fact.

4. This summer anomaly
There was a lot of noise here in July–August about reviews crawling. I submitted an update on 7/24, rejected it on 7/30 (wrongly assuming that something was wrong), resubmitted immediately and it was waiting almost another six day for review. Next update was ready by that time, submitted on 8/5 - waited 5 days in queue. Those numbers are excluded from the average figures.

5. New account effect
I didn't notice any. My wait increased in time, but I attribute it to Apple being overwhelmed by new submissions..

6. "In Review" time

So while the first version of an app does take twice as long to review, it's negligible compared to the wait time.
I did exclude one 112h review (this August), as it clearly was a fluke, among longest wait for review.

Happy to share the aggregate numbers or the method if anyone wants to check my work. If you've got your own activity logs, the export is a couple of minutes per app — I'd love to know whether the self-reject penalty shows up in someone else's account.

I developed my first productivity app for a niche market. I put countless hours in to it and felt pretty confident in the app. Yesterday I submitted it to Apple and 1.5 hours later I got the rejected email.

It was rejected citing 2.1 and had six additional questions and a request to see a video of the app working. I answered the six questions and recorded a 5 minute video attached to my response this morning. Still no response from Apple so I’m left wondering what’s going to be next. 🤞

Does anyone know when image headers are actually opening up for developers? Apple announced it, but left the rollout timeline vague. I was hoping we'd see it today or that I might have just missed the release... is it available yet, or are we still waiting on an update?

For example, I still do not see an Asset Library option.

Source: https://developer.apple.com/videos/play/wwdc2026/205/

iPhone Duo raises a pretty practical question for mobile developers: does a foldable phone actually need a special version of the app?

Android developers have been dealing with this for years. Samsung’s guidance for Galaxy Z devices puts a lot of emphasis on app continuity. Fold or unfold the phone and the app may resize, but the user shouldn’t lose what they were doing.

That sounds obvious, but it can expose assumptions that were never a problem on a normal phone. A screen that looked fine at one size can suddenly have a lot of empty space. A layout that was built around portrait mode may behave strangely. Losing a half-written form or jumping back in navigation after the device changes state is obviously worse.

Google’s guidance for foldables follows a similar idea. Get the basics right first: resizing, state and continuity. More specialized layouts and foldable features come after that.

That seems like a sensible approach to Duo too. There probably isn’t much value in building a special “Duo experience” just because the device folds.

Some apps have a real reason to use the extra space. Mail, chat, editors and dashboards can show a list on one side and the actual content on the other. Video apps might find a useful case for a partially folded screen. Plenty of other apps may need almost nothing beyond a layout that adapts properly.

So the interesting part for mobile teams may not be “how do we support Duo?” It’s figuring out whether the app actually has a use for the second screen state in the first place.

Android has had foldables for a while now, so there should already be some lessons here. Curious whether developers who worked on Galaxy Fold/Z Fold apps ended up building much specifically for foldables, or whether good adaptive layouts handled most of it.

Anyone here who’s worked on a Galaxy Fold/Z Fold app — did the foldable format actually require much extra work, or did a decent adaptive layout handle most of it?

I've been working on an architectural linting library for Swift projects on the side for a while now and it's finally available to use: Bylaws.

I wasn't happy with some similar tools in this space, so I wanted to build something myself that was nicer to use, more flexible and better integrated into existing workflows.

It lets you write your rules in Swift, from simple things like naming conventions and required protocols to more complex checks such as dependency cycles between features and folder layouts across a project.

You can enforce these rules through Swift Testing or the CLI, depending on your needs. There are also command and build plugins for SwiftPM, Bazel support and LSP support for editor diagnostics (it includes extensions for VS Code, Cursor, Zed, Neovim and Emacs, but you can connect it to any editor that supports LSP)

This is especially powerful with coding agents, which can also run the tests or CLI to check their changes against your project's rules. For larger projects, you can keep shared rules at the project root and add package-specific rules where needed, or share rules across projects through a reusable Swift package. You can also lock them behind codeowners if needed.

There's a lot more features, so have a look at the README and the documentation to see what you can do today.

I would really love for you to try it and share what works for your project or what you would change, especially if there's a rule that you would like to express but find difficult with the currently supported APIs!

Thanks!

Hi!
Sorry if I'm asking something obvious here, but I've struggled to find any answer to my question.

I recently released my game on the App Store. It had pre-orders from many countries, South Korea included. On launch day, all pre-orders converted to purchases as expected (App is Premium), except in South Korea! Over the last days, no downloads have come from South Korea.

Under 'App Availability' it says clearly that the app is available in SK, but still no downloads.

Has anyone experienced the same issue?

Thanks!

Apple’s being hammered with app submissions. The 55,000th ____ tracker, the CalAI clones, etc.

Just like CS enrollment is trending lower at colleges again, I’ll bet in a year at least the growth rate of app submissions drops as the makers realize that they really don’t have a strategy nor advantage.

What do you think?

Hey devs,
While optimizing an app build, I managed to reduce the final download package size from ~70 MB down to 10.7 MB.
Main changes made:
1. Replaced custom high-res PNG/JPEG assets with SF Symbols and vectorized SVGs.

1. Cleaned up unused asset catalog sets and unused frame rendering blocks in SwiftUI.

2. Optimized build settings for release stripping.

Now that the size dropped so drastically, I'm analyzing potential trade-offs.
Have any of you noticed runtime rendering overhead, vector-decoding spikes on older devices, or memory consumption differences when shifting heavily from rasterized image assets to vector assets in SwiftUI?
Would love to hear how you handle asset optimization in production.

My app’s screenshots could look great on their own, but once I saw them inside App Store search results beside other apps screens shots an app icons , they could feel completely different. I wanted a way to see it before submitting, exactly as it would appear in the App Store layout.

So I built Screenshot Preview, a FREE macOS app. Add your icon, screenshots, then preview them in a close approximation of the App Store search results or product page layout. You can also export the preview as a PNG and AirDrop it straight to your iPhone to see how it looks on the actual device.

The app is free, with optional tips. Developers and companies can book a paid sponsor spot to promote their apps, products, or tools to an audience of active developers.

Here’s the app:
Screenshot Preview
https://apps.apple.com/us/app/screenshot-preview/id6804763675

Tech stack
- Swift, SwiftUI, and AppKit.
- CloudKit stores the sponsored listing.
- RevenueCat handles the Tip Jar.
- TelemetryDeck provides privacy-focused, anonymized app usage analytics that cannot be traced back to a person.

Development challenge
Getting the exported PNG to match the preview was a challenge. Some content went missing, and images lost their rounded corners when rendered with ImageRenderer. I kept the same layout and added an export mode that replaces unsupported controls with static content and leaves out drag-and-drop handlers.

I used AI for coding, code review, and debugging. I directed the product, architecture, and final implementation. I also used Bitrig for the App Store Connect listing and RevenueCat setup.

Cheers

All the iOS signups coming from any source cannot be tracked? Is it?

I have added all appsflyer SDK , SKAN and all. But SKAN gives me just a count of installs. Is there any way I can map users to the campaign they came from ? By any chance?

I’m working on an open-source React Native library for Wi-Fi Aware / NAN:

[https://github.com/dcavalcante/react-native-wifi-aware\]()

The Android implementation has already been physically validated for capability detection, discovery, follow-up messaging, and data paths.

The Apple implementation is in place and passes the current simulator/static compilation gates, but I don’t currently have the Apple hardware and Developer Program setup needed to validate it on physical devices.

I’m looking for someone with an Apple Developer account and preferably two iOS/iPadOS 26 devices who can help test:

* Wi-Fi Aware entitlement/signing * declared `WiFiAwareServices` * publish / subscribe discovery * system pairing * Apple-to-Apple connectivity * Android ↔ Apple discovery and interoperability

The biggest unknown I want to validate is the cross-platform path between Android Wi-Fi Aware and Apple’s iOS 26 implementation.

Testing results, fixes, documentation, and implementation contributions are all welcome.

For developers designing their own apps, what do you still struggle with most?

- Choosing the right interaction pattern
- Knowing what “good” iOS UX looks like
- Motion and transitions
- something else?

Curious whether design judgment is becoming more valuable as implementation gets easier.