Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI

developer.apple.com

Post reply on HN
Print view View original

361–370 of 394 posts

Re: SwiftUI

#361

Post by eugeniub »

jamil7 wrote: post #312
eugeniub wrote: post #137

Earlier quoted context omitted.

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/

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.

Re: SwiftUI

#362

Post by eugeniub »

BrandonSmith wrote: post #346
eugeniub wrote: post #137

Earlier quoted context omitted.

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/

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.

Re: SwiftUI

#363

Post by eugeniub »

charrondev wrote: post #216
eugeniub wrote: post #207

Earlier quoted context omitted.

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.

Re: SwiftUI

#364

Post by eugeniub »

myko wrote: post #268
eugeniub wrote: post #207

Earlier quoted context omitted.

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

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.

What UI framework are you talking about? Flutter?

Re: SwiftUI

#365

Post by myko »

eugeniub wrote: post #364
myko wrote: post #268

Earlier quoted context omitted.

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.

What UI framework are you talking about? Flutter?

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

Re: SwiftUI

#366

Post by myko »

yoz-y wrote: post #298
myko wrote: post #268

Earlier quoted context omitted.

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 requi…

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.

Re: SwiftUI

#367

Post by myko »

Cthulhu_ wrote: post #338
myko wrote: post #262

Earlier quoted context omitted.

True but who does this? The Android framework isn't built to support that reasonably at all, at least not until Jetpack Compose becomes viable.

Wasn't that the default way of doing things in Android? That is, build your ui's in XML?

By writing views programmatically in Android they mean writing them in Kotlin or Java, not XML. Almost no one does this.

Though Kotlin has an interesting looking DSL for doing that named Anko.

Re: SwiftUI

#368

Post by appliaison »

Now, will someone be a sweetheart and write a transpiler that will transpile AndroidXML to SwiftyUI and SwiftyUI to AndroidXML. Also, while you're at it, please write a transpiler for Flutter to SwiftyUI and SwiftyUI to Flutter. K. Thx.

Re: SwiftUI

#369

Post by zapzupnz »

Quenz wrote: post #320
zapzupnz wrote: post #221

Earlier quoted context omitted.

Because not all of your "fellow developers" have the same priorities as you. For a lot of developers, targeting just the Apple platforms is still a worthwhile investment in itself: Apple's customers tend to pay higher prices for quality Mac software — yes, outside the Mac App Store, too — and they will very often be happy to pay for the accompanying iOS app if it's worth doing so. There have been Apple-only developme…

There sure are a lot of developers only interested in developing for Apple platforms. But wouldn't it be beneficial for Apple to extend the framework outside their ecosystem? I doubt the reason they haven't is to limit expending resources.

It wouldn't be beneficial to Apple.

The direct comparison one might make is to Microsoft, who recently opened up .NET to have official Linux and macOS compatibility. The result is that enterprise and small businesses can deploy Microsoft technology on their Linux servers, possibly moving towards deploying on Azure. The cloud is Microsoft's big money maker — providing cross-platform tooling is one way to support that business.

Apple makes their money from selling devices, not from offering a cloud infrastructure. Therefore, it makes no sense for Apple to offer their high-quality tooling and frameworks for other operating systems — the aim is to have developers selling their software for Apple platforms, eventually having people pay for services like iCloud storage, Apple Music, Apple TV — and then stay with using Apple's hardware. Maybe a person tries an iPad. Then they get an iPhone. Then they get a Mac.

Apple recognised this about two decades ago when they officially cancelled development on the Windows version of Yellow Box (later to be named Cocoa, the base frameworks for Mac and the ancestor to UIKit, the base frameworks for iOS). It has worked well for them.

Is it right or wrong? That depends on one's perspective about lock-in. However, I don't see a problem with it in the sense that nobody is being duped — unlike Microsoft in the 90s practically forcing Internet Explorer on practically every PC available, Apple doesn't have a market monopoly.

Apple's strategy has remained consistent since the early days of OS X: you don't trap users, you make simply make sure they never want to leave. That's the pitch they make to developers, too.

Re: SwiftUI

#370

Post by mpweiher »

pier25 wrote: post #356
mpweiher wrote: post #326

Earlier quoted context omitted.

> other than being a reimplementation in some cases. Hmm...that's pretty much the entire difference between native and non-native controls.

Yes, and that is precisely my point. A previous commenter implied that there somehow native controls were technically different than Flutter controls. Obviously the rendering stack is different but Skia is as native as Quartz is.

That was the exact opposite of my point.

Native widgets are those of the native widget toolkit. I can use the underlying drawing libraries to draw widgets that look vastly different and implement behaviours that behave vastly differently from the native widget toolkit.

The point of native widgets is that they are the same, not that they are drawn using the same underlying technology.

So the fact that you are using platform libraries to draw those non-native widgets is not at all relevant. After all, what else are you going to be using?

Post reply on HN