Steve Troughton-Smith
If you've never really considered the complexity in updating an app for a new iOS release over the summer, welcome to my hell:
I'm currently working on two completely different versions of the UI in Broadcasts. One, using the old layout, which needs a reasonable amount of fixup. And another, using a new layout using all the newer APIs, currently very broken and is going to need a mountain of work to finish, and from my initial experimentation looks like it's unable to do all the things I want
Will I ship the ambitious rewrite that won't be as pretty but will be way more flexible for folding phones? Or will I ship the battle-tested existing UI that doesn't handle transitioning from small to large mode very well, and won't have a good solution for the 'middle' posture the platform now demands? I really don't know right now. Many of the APIs are unfinished and/or broken, so it's really up in the air. I will have to progress *both* far enough to make a decision
Speaking of rewrites, this redesign is finally going to push me to finish rebuilding my playback bar in UIKit. It now has to scale down a size class further to handle the new iPhone tab accessory mode, so it makes sense I do this here rather than in the doomed SwiftUI version.
My codebase basically has at least two versions for every view controller you see onscreen, either as new un-shipped versions, or versions I replaced a while back but never fully ripped out. I can sense a clean-out coming
So what if I sacrifice the morphing tab bar, but hide/show a tab bar when the sidebar is opened/closed instead? That way I can keep my custom sidebar logic and ornamentation, but also have a unique middle posture layout 🤔
It's an option — probably the most sensible one — but I'm undecided
There comes a moment in every major update you build where your app really starts to fork from the previous version and it becomes hard to imagine going back. I'm starting to feel that way about Broadcasts 4 now. At the time everything I did felt like tiny changes, but looking back now I'm like "wait, I did all of that since June?"
The question remains, will anybody actually like what I've done, or was I on the wrong path from the start 😅
The most important thing I need to do for Broadcasts 4 is move the monetization to a subscription model (for new users only), something I've been talking about for way too long at this point and just been too afraid to pull the trigger on.
And I think part of that is going to involve making the app iOS 26-only — if I'm going to offer subscriptions, I don't want that to tie me down to supporting older versions of the OS indefinitely, when this is very clearly a line-in-the-sand update year
There is an alternate timeline where this is what became Broadcasts 4. A timeline without crunching for six months to port to visionOS, without despair at an iPad platform vision with seemingly no future, without disgust at Apple's handling of antitrust issues, all of which combined I lost a good 18 months to
I made two tiny changes and it transformed how I feel about the Liquid Glass in my iPhone design
1) I use 0.99 white/black instead of systemBackgroundColor
2) I added a stronger fade underneath my tab bar
Both of these changes could trivially be implemented by Apple
There is a ton left to do in Broadcasts before I can even start pushing it to TestFlight — it is the most changed of any of my apps, touching a lot of the parts of the system that look or behave badly even at this late stage.
Plus, it adopts the new Music/Podcasts design, and I want to see how people react to Apple's, first 😅
At the moment I'm not targeting 26.0 or September, as I want to get everything else out the door before I turn my attention back to it. It will be done when it's done
"Why doesn't the last-played station automatically pre-load at launch?"
Good question. So now it does. Same amount of clicks, but no need to scroll
You ever come across a one-line-of-code change and wonder 'how the heck did I not know this?'
Today's example: setting .accessibilityTraits = .header on your collection view section headers.
Now you can navigate blisteringly fast between them with VoiceOver, like I've enabled in Broadcasts
The three states of Broadcasts' new purchase model (may not be final wording or layout):
1) No purchase
2) Existing IAP with optional upgrade to subscription
3) Subscriber
Completely noninvasive grandfathering for existing users. Maybe I should be smarter about that — alas. It gives me plenty of levers to pull in the future, should circumstances require
Today's drive: combining Search and Browse in Broadcasts. Conceptually, it fixes a bunch of problems I was wasting energy trying to design around. I also worked on the list section header behavior, which now uses a hard style blur.
I started putting the v4 features behind individual feature flags to try and rein in the scope of what I'm working on so I might actually have a chance of shipping. I'm getting there.
Christian Lynbech
Trevor Kay@stroughtonsmith Sometimes you’ve gotta just draw the line in the sand and save it for the .1 release
Had this when I was working on Screen Sizes 3 😅
Oliver BuschObviously assuming this isn't automatically happening on the OS level.
Fabien
Colin
Hunter Chorey
Shane
Jochen Marschall@stroughtonsmith
I am fairly certain it is not a bug on your end but rather on Apple’s. But here’s what I run into all the time:
I set up a shortcut on my iPhone to open Broadcasts and play the last used radio station.
It basically only works if Broadcasts was open very recently – like the last open app before the one I might be in.
I usually do it via voice command on my watch. Siri always tells me “That’s done.” But if Broadcasts wasn’t open recently nothing happens.
Thank you!
DHa
Jurgis Kirsakmens- user uses multiple AppleID accounts (sometimes in different countries) and have downloaded app with another account (signed with different AppStore account)
- user is logged out from AppStore account
I use local receipt validation (or send receipt to AppStore validation endpoint to get json back) as a failover.
wladisge