Hacker News Reader

Comment by fphilipe | Hacker News Reader

Personally, as an iOS developer, this is by far the biggest announcement.

Haven’t had the chance to dig deeper, but the comparison between the UITableViewController and that snippet containing just declarative code looks absolutely promising.

The only downside is that we’ll have to wait one or two years before we can use it if older iOS versions still need to be supported. Let’s hope for extra quick adoption of iOS 13.

View on HN

Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.[1] Last year, iOS 12 didn't drop support for any devices. The iPhone 6 is a very popular device, and was still sold by Apple less than two years ago.

[1]: https://iosref.com/ios/

According to Mixpanel, the 5S / 6 / 6 Plus together account for a bit less than 10% of iOS devices they see. So it's not as big of a drop as one might expect.

https://mixpanel.com/trends/#report/iphone_models

That is way more than most companies will part with. If support drops substantially below 1% we can talk again.

Yep, if your margins are 20% and you lose 10% of your user base and revenue, you just lost half your profit.

I must be missing something here. Assuming on a napkin that all users roughly generate the same amount of revenue, losing 10% of them will lose you 10% of your profit, no?

If anything, users of really old iPhones are likely to be less spendy so you're losing less than 10%.

It depends on how you're calculating it: if you have fixed costs, then yes, your profit drops 50%; if your costs scale with number of users then you go down 10%.

Profit is revenue minus expenses. Supporting more versions of iOS essentually means greater expenses. So the decision to drop support of older iOS versions is basically the questions of whether or not the additional expense of supporting it is greater than the additional revenue those users generate. For a company like Facebook, the revenue is much greater than expense, while for a smaller company, it's probably smaller.

>Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.

That really is a bummer, I have an iPhone 6 and it's still alive and kicking.

day before WWDC:

   was rocking the 6

day after WWDC SwiftUI announcement:

   look ma, shiny new xr lol

Does this include 6 Plus? I grabbed one second hand recently and it's been working great for an iOS side project, would be sad if I couldn't use any of this.

It includes 6 Plus. 6 and 6 Plus are essentially identical devices internally, they have the same A8 chip and 1 GB of RAM.

I smell a low-cost iPhone offering late Summer.

Frankly I think they'll just keep selling iPhone 8 for another year but drop the price down by $50 or so to $549. Or maybe if we're lucky $499. Either way they won't release a serious budget phone like the iPhone SE for $399 like they did in 2016. That year, Apple's flagship phone was $649. This year the flagship is $999.

Lower than the $0 they're already offering the Xr at? :)

One thing that Google does right with Android is back porting to older versions.

I'm having a hard time figuring out how this statement can be even remotely accurate.

Whenever new frameworks or pieces of android come out, they are often accompanied by a compatibility library that you can ship in your app to use the new API and target older platform versions.

Ok, that's a fair point.

Do you develop Android apps?

Google also announced a declarative UI framework. It's in the early stages and is open source. Android is on 9.x but that framework will run on much older versions of Android.

Meanwhile iOS 12 might be on 85% of iOS devices but it wont ever see SwiftUI.

Vast majority of the people with iOS12 will update. Also, at least on the announcement page, there seems to be no mention of iOS13 required for running apps using SwiftUI. Up until Swift 5 the whole runtime library needed to be shipped with the app and it is quite possible that a SwiftUI library could be shipped and run on iOS12.

Edit: On Apple developer forums I've read that the library is annotated with iOS13 requirement.

The vast majority of folks will update right away.

Not enough to convince my stakeholders that we don't need to support at least one major version back.

I'll probably fight that harder this year than in previous years - SwiftUI looks incredible and any AutoLayout code already feels like legacy.

Yeah, I agree that Apple should have added at least one version worth of backwards compatibility if they want to see quick adoption. I suppose one could hide the whole view in defines and lug two implementations but that is not much better than waiting for one year.

What UI framework are you talking about? Flutter?

Jetpack Compose - https://developer.android.com/jetpack/compose

It will not be on 85% of iOS devices once iOS 13 is available.

Sure, but my company (and I assume most) will maintain support for at least the last two major versions of iOS. We wont be able to be minimum iOS 13 until ~September 2020 at the earliest, probably not until early 2021.

I understand why, I just wish they could release this open source like Jetpack Compose. Would've been a great way to introduce SPM to Xcode and iOS as well.

> I'm having a hard time figuring out how this statement can be even remotely accurate.

I'm not even an Android developer and I already know that tons of Android libraries get back ported to older Android versions. They have to. Nobody runs the latest Android.

It's a bit shocking to get downvoted for a statement that's undeniably true.

Of course, that’s because most manufacturers don’t push updates to their devices and many users are using versions from years ago.

True. But supporting iOS 12 would mean I could start working on SwiftUI apps today.

Do you have a link to the comparison?

It was during the event, they just displayed an overly dramatic LOC comparison on the screen between a few page-downs on a longer Swift file, then the next screen showed a ~10 line block of code which does the same thing. Followed by the standard audience applause.

The livestream hasn't been uploaded yet but I'm sure you could find it in one of the live blogs.

Part of that comparison (on the "before" side) was a bunch of Cocoa autolayout code. It's verbose and annoying, only mitigated if you're using Interface Builder, which has its own significant downsides. If the declarative form in SwiftUI supports a saner approach to managing and adjusting layout, then there's absolutely nothing overdramatic about that comparision. It's a potential game changer.

Thanks! Indeed it's impressive.

Nah, do what we do on the web: Polyfill. It wouldn't be perfect and have all the interactive tools, but a API-compatible lib that abstracts over AppKit / UIKit seems doable, then just switch imports when the future arrives.

> but a API-compatible lib that abstracts over AppKit / UIKit seems doable

…have you taken a look at development for Apple’s platforms lately? Nobody has been able to do this yet.

People have (many companies have their own frankenstein version), but maintaining them is hell and I'm not sure I'd trust the OSS community to do a great job of it.

Reply on news.ycombinator.com