T O P

WWDC21 in a nutshell 🥲

WWDC21 in a nutshell 🥲

timatt1

This is always a running joke with WWDC at my work. "This new feature is awesome! I can't wait to use it in 2-3 years when we set our deployment target to this new version of iOS!"


Ast3r10n

Honestly, that’s the employer’s problem. If everyone just switched to the new deployment target, we would have a much better App Store in general. Supporting the 3 people on iOS 12/13 just isn’t worth the hassle. We have a deployment target at iOS 10. 10!!! NO ONE is using that anymore, come on.


timatt1

According to [this](https://david-smith.org/iosversionstats/), over 20% of users are iOS 12 or 13 right now. Those numbers line up with what see in my company's analytics as well. It would be great if users would upgrade to the latest version quickly but that just isn't going to happen.


-mrmr

Surely you would just use the [official data from Apple](https://developer.apple.com/support/app-store/) rather than one persons app, unless I'm missing something.


OrkhanALikhanov

Well, those are global numbers. Poor countries will have older iphones and to have a good share of the market, you need to support iphones of those people. Even in global market, whatsapp, telegram etc support ios 10 devices even today. Probably gradually dropping support based on internal user stats rather than global data


Ast3r10n

This. I would honestly only trust Apple with this. I prefer being on edge as far as technology goes rather than support a couple of guys who won't change their iPhone 4Ss.


timatt1

I think almost any dev would love to be on the cutting edge. But unfortunately I know I'm limited by costs to our business. Cutting off iOS 12 and especially iOS 13 would cost my company a lot of money. In addition customer support also factors into the decision. If we release a feature on the web that a large number of our users can't use on mobile because our deployment target excludes 10-20% of our users, it would inundate our CS team with support tickets. It would be nice if Apple were like Google and released support libraries to allow older version of iOS to use new features, even if only supporting a couple versions back.


onthefence928

Until you have a giant code base based on angular js and they release angular 2 and it’s completely incompatible with old angular js code and you can’t afford to spend all year rewriting the entire app so it stays on angular 1 for long enough that react js looks pretty good and it’s gonna be a year or more to rewrite everything anyways might as well switch to react!


Ast3r10n

Unless you work in banking, there’s no chance you have 20% of your users on iOS 12. Statistics say definitely otherwise.


timatt1

We have between 10-20% on iOS 12 **&** 13 combined. When I last checked around a month ago, it was over 10% on iOS 13 and around 7% on iOS 12.


Ast3r10n

At least iOS 13 supports Combine. The real issue here is supporting 12. Or 10, for that matter…


timatt1

I think our numbers skew a little closer to the link I posted than to Apple's because we have a lot of iPad users and users will use iPads for a lot longer than iPhones and will eventually lose support. But even using Apple's official numbers it still shows a sizable chunk of users on older versions and most businesses can't justify cutting off 10-15% of their possible userbase which was the point of my post.


ThePantsThief

% of all users vs % of your own users.


valleyman86

Not usually that helpful if you have your own metrics. If your demo is mainly older people they tend to not update often so you can't just drop them because they aren't with the latest.


androideris

you have not thought about the SDK developers, like myself... We need to lower our target as much as possible since there is always few clients who set app target to 11-12


SonosArc

Lmfaooo same. This kinda crap is making me seriously consider starting to do leetcode problems for interviews. Then again that's the worst part of being a dev so idk


MrStahlfelge

Consider yourself lucky. I am an Android dev and have to wait 8 years to get rid of all the legacy stuff. ;-)


well___duh

No way your app is being used by a good portion of users under API 21


MrStahlfelge

For my main app <= 4.4 is 1% at the moment, but paying users are more on the latest version of course. Yes, is time to get rid of 4.4 now, maybe even 5.x. But it is still not safe to rely on Java 8 or system-side dark mode support.


well___duh

Unsafe how? Java 8 and dark mode work just fine


MrStahlfelge

Yes, on 8+ or 9+ devices. For all below, you have to make a dark/light setting for your users yourself or need to rely on third party libs, for example bouncy castle for crypto operations not available. But we are off-topic here.


cyberspacedweller

This is why I didn’t learn Swift for ages. That and it was constantly changing. Kind of regret it now though since I’ve left it a bit too long.


SirensToGo

The one nice thing about the Swift runtime being baked into your app was that you could at least take new language features back to older versions of iOS


AberrantRambler

New runtime features like async/await!


SirensToGo

new runtime features like Combine!!!... wait


TurtleMode

The stupid .badge() in SwiftUI in list items requires macOS 12…. Ffs it’s a stupid label with a background and rounded corners!!!


gormster

Polyfill time?


RDSWES

Apple has always been this way.. why would you expect them to change now?


Rudy69

Some people had a sliver of hope with ABI stability


kaphacius

Why is this different than any other api? Bc it's a feature of the language itself?


MotorolaDroidMofo

It shouldn't have mattered, Apple just doesn't care. They did this with SwiftUI too, which also had no reason to be locked to any specific iOS version.


bbatsell

I firmly agree that I wish Apple cared more about backwards-compat. But you're very wrong about there being "no reason". We are building on top of APIs that require system-level frameworks to be installed and available on users' devices that actually perform the work we ask of them. Apple makes the strategic choice to always develop new functionality on a branch targeting the next version because they often require large, coordinated changes across multiple frameworks and services, and it would take significant extra effort to backport those changes to already-released, stable OS versions. Like I said, I wish there was a healthier balance, but it's not nearly as diabolical as the implications in your post. My understanding is that they were hoping to implement async/await simply as compiler syntactic sugar, which would have allowed it to be backwards-compatible. However, there were some changes required to the Dispatch framework in order to make async/await work the way they wanted it to. I think Apple is trying to work around those, but couldn't guarantee that effort's success by WWDC so as of right now it is iOS 15 only.


MotorolaDroidMofo

I guess I disagree with that whole approach. Why does concurrency or SwiftUI have to be shipped with iOS itself? On principle, they don't. Android is a total mess, but at least you can use Kotlin's coroutines and Compose with basically any Android version, because those features were never part of the OS itself.


frozzyk

Why android is a total mess?


powerje

Works for Android


remote_socket

SwiftUI and Concurrency are different beasts entirely. Concurrency relies on runtime features and has tight OS integration but with trade-offs Apple could backport it like they explained on the forums. It would just take a heck of a lot of work and be a suboptimal experience because the tight OS integration would be missing. SwiftUI on the other hand is a framework that’s bundled with the OS and has dependencies on various other system frameworks. Backdeploying SwiftUI means you’d have to include things like UIKit and anything else SwiftUI depends on. That would make your binary HUGE, probably several hundred Mb. And you wouldn’t “benefit” from free bug fixes when Apple does bug fixes like you do now because frameworks like SwiftUI aren’t bundled into your app and you always load the version that’s on the system. I don’t like Apple’s approach either but comparing SwiftUI and concurrency like that is just wrong.


jNSKkK

There are discussions as to whether they will update the iOS 14 runtime to support it. Not 100% confirmed yet, though.


tudor07

How could they do it?


jNSKkK

In an iOS 14 update? I’m not sure what you mean.


tudor07

So they still rely on people updating iOS


jNSKkK

Yes, but that’s a moot point really.


RussianDeveloper

Swift is basically fine tuned JavaScript. Try to convince your engineerring managers or senior leader ship to force update your applications and force users to update those applications, many apps do this a lot of the time and explicitly say we need you to install an updated version of this app it’s because they are updating their code banks for reasons such as this. So yes it is definitely the employers problem that is delaying innovation to be released to their user base. Users need to be encouraged to update their devices otherwise they’re going to stick on old deprecated versions for a long time


jackphumphrey

Not related to this post but something I would like to comment on which I might get a lot of flack for in this sub. But I am learning swift and coming from web development. And the difference between swift in JS seems so minimal that I don’t understand why Apple goes through all the work themselves and for developers to create a new language. Like why did they not make something like NodeJS but more advanced/tailor? Couldn’t the same results be achieved but allow greater access to the platform, which is what seems to suggest they want? This same thing can also be said about flutter/dart with google. Maybe I’m too early in the leaning process to understand why this wouldn’t be acceptable or better but from my point of view it seems like only pros minus iOS developers having to learn JS if they didnt already know it but like I said JS & swift are so similar that would be the case with both languages.


remote_socket

There are huge differences between the two. For one, Swift has strict types and JavaScript doesn’t. Swift is compiled so the compiler can catch errors and JavaScript doesn’t have that. Swift has support for generics, JavaScript doesn’t. You can define protocols in Swift, JavaScript doesn’t have that. That’s just a couple of features that make Swift very very different from JavaScript


RussianDeveloper

Yes there are implementation differences specific to each language. I did not say that they are identical.


remote_socket

“Fine tuned JavaScript” doesn’t even begin to capture the differences. The only thing JavaScript and swift have in common is their C-style language roots


cutecoder

OTOH loons like SwiftUI is ready to graduate…


EpicSyntax

At our company we are always supporting the current version and the one before. It's a necessity for most of our clients. I still can't understand why Apple is not adding backwards compatibility to some features like the async/await. It's a freaking compiled language. Just polyfill it god dammit.


Thermometer91

I thought async/await being iOS 15+ was a bug? Seem to recall reading something like that


faja10

Bug? No They are trying to find a way to port It to previous versions? Yes Will they succeed? Propably no


Thermometer91

Apparently it was mislabeled as a known issue, which implied it would be fixed in an upcoming beta. You’re right, they are trying but we shouldn’t expect this yet: https://mobile.twitter.com/v_pradeilles/status/1402249026163154955/photo/1


TotallyTiredToday

Don’t expect it at all. Yet means you’ll be disappointed when it doesn’t happen.