Elaborate. I’m a RN dev. Pure curiousity, if you have valid points I wont bash, only be grateful to hear them.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple's Swift Working to Support Android App Development
- Thread starter MacRumors
- Start date
- Sort by reaction score
Tell me you've never used RN without telling me.
Seems to work fine for Instagram, Amazon, MS Outlook, etc.
It does not.
This is all about using the recent Swift/Java interoperability to bridge Swift code with the JVM so that it can access the Android SDK. That is, Swift is now one more language that can write Android apps. But has no bridging with other Apple SDKs. For example, SwiftUI doesn't exist on Android so can't be used in an Android app.
I can see this makes sense for Apple for their Android develoment, where they can now use more of their Swift expertise. But it's really all Android-specific development.
absolutely not the case
Swift already has first-class support for Windows and Linux, and there's not a hint of SwiftUI over there. Just consider them separate and unrelated projects.
Last edited:
Utterly meaningless. If anything, pointing out that the likes of Amazon and Microsoft use it speaks poorly of React Native.
(Yes, I've developed a couple apps with it)
The effort to improve Swift usability on Android has been a long-running community effort, and it sounds like they are now close enough to become an officially supported platform, which is the point of this.
There are apparently Apple contributors to the group and I suspect this work (along with Java JNI support) is related like you said to Google Play Store apps that Apple provides - they have internal devs now who would like to write as much common code as reasonable in Swift for their integration code and apps for other platforms. That includes Android/Google TV support for AirPlay and Apple TV+ as well, most likely.
That doesn't mean Apple is trying to turn SwiftUI into say a Flutter competitor - they haven't aimed toward 100% parity with AppKit/UIKit on their own platforms. But you can have a lot of complex business logic and network connectivity logic behind say the Music app; it would be nice if they could share that chunk and make sure it is robust everywhere, even if the code that puts downloaded album covers in a grid is still platform-specific.
I think this is also Apple's recommendation toward cross platform development as well, barring a few oddities like Catalyst.
Last edited:
So, a couple things… first, the Swift group has a lot of autonomy in Apple. Their goal isn't to sell iPhones, it's to make Swift as good as possible, and that means being a real open source project with all the philosophy that comes with that.
More importantly: the stated goal of Swift is not “to be a great language” or “to be a modern Objective-C” or whatever. They want it to be the default language for computer science. That means that it should not just be performant, but it should also be the best way to express conceptual ideas in computer code.
That role was filled by Java from roughly the mid-nineties through today. CS students still study Java all day but don't spend a minute of their professional lives in it.
Personally, I've spent a bit of time writing iOS and MacOS apps in Swift, but in sheer number of hours, I've spent more time writing Swift for Linux servers (see https://vapor.codes). And as of a week ago, I've started dabbling in Swift for Godot, which was created by the guy who brought Microsoft's C# to Linux and every game platform under the sun under the "Mono" framework.
Apple understands that in order for Swift to fulfill its ambitions, it must be everywhere, not some kind of iOS "secret sauce."
One could say there's gradual process where Swift the language is independent, and Apple's development on Swift is specifically toward Apple goals - but as a more equal contributor.
It will never be as fully independent as people would like, because Apple would likely use and ship features whether or not the community at large accepts them. However, we see initiatives like Swift on Windows come about where Apple has almost no interest (until someone is crazy enough to attempt rewriting the iTunes codebase). We also see Apple contributing more heavily to Swift on Linux (and adding things like Containerization) when they increase their hosted services, and perhaps have an AI initiative that is making them deploy and maintain their own compute servers at scale.
countless React projects, only two in React Native.
It’s not as awful as Electron, of course.
Oh definitely, for sure.
Even within the Apple ecosystem, there was a lot of consternation over the changes to Swift that were necessary to make SwiftUI work the way they wanted.
Not really. They won't bring SwiftUI to Android because that would mean using the IOS design for Android. What they want is just for Swift to be used everywhere, even replacing C++ and Java.
I've used it plenty. We rewrote all our React apps because like I said, it's trash.
Just off the top of my head ....
- Expand Swift's Adoption and Ecosystem: this may relieve increasing pressure from Flutter and React Native.
- Enterprise Developer Retention: enterprises want to develop from as few languages as possible. This can potentially solidify Swift as a systems-level Language
- Toolchain Dominance via Xcode. Aside from the development part, making Xcode/Swift the gold standard for mobile development will help to maintain Apple's hardware sales. This will also address Android’s dominance in emerging markets in Asia, Africa, and South America where there's a lot of growth potential.
- Antitrust and Openness Optics
Regardless, I'm not so sure if Apple has the intestinal fortitude to follow through on this. I anticipate this might just be another gimmick and not really pan out to be a full-fledge commitment by the leadership team.
Apple should've done this five years ago before or during the pandemic. They've lost the rock solid relationship they had with the creatives and dev community that they once had. It looks like the walled garden strategy is no longer a sure thing any more. I hope they can turn things around.
Kotlin multiplatform has, I think, a similar goal. The UI code isn't cross compatible, but you can make model code cross platform a lot easier. My team kicked the idea around of using that, but we would rather have had a Swift code model we could export to Android, not Android/Kotlin to iOS/Xcode/Swift.
But what really still needs help more than anything is the nightmare that is Android studio. I have a part time project I have to update, and every time I need to fire up AS it's a nonstop barrage of Gradle updates and inscrutable code change warnings. But Xcode taking over all Android development is far beyond the scope of this topic. ;-)
But what really still needs help more than anything is the nightmare that is Android studio. I have a part time project I have to update, and every time I need to fire up AS it's a nonstop barrage of Gradle updates and inscrutable code change warnings. But Xcode taking over all Android development is far beyond the scope of this topic. ;-)
I think in C++ but have written in Java both at work. I’m surprised that students wouldn’t still be using Java for their jobs. What is replacing Java?
It's a good point, and I also do take the point that multi-platform "layers" can add problems as much as fix them. I've used plenty of them over the years and there are wins and loses - no doubt about that. But they can work well in some situations. Like most stuff in the world of programming, there's very rarely one-right-way. If only that magic bullet did exist. Then again, coding would then become so simple we'd all be out of a job.
They can bring SwiftUI to Android without bringing the iOS
.glassEffect() to Android. And I suspect that they will, because the alternative is letting Kotlin dictate the UI, and Kotlin Multiplatform on iOS just looks like you've taken an Android app and dumped it into iOS.
Nothing. Most CS jobs in my area are Java (although it's using Spring Boot, which may as well as be its own flavor of Java at this point) or C#.net, although python is getting really big due to AI.
I don't think the AIs really care which language you get them to write your apps for you in.
I've not written much code in the last year but I've produced more code in that year than any other period in my life thanks to AI.
As long as I can still proof read it I'm fine with any language. ObjC, Swift, Java, Kotlin, I dont really care.
I've not written much code in the last year but I've produced more code in that year than any other period in my life thanks to AI.
As long as I can still proof read it I'm fine with any language. ObjC, Swift, Java, Kotlin, I dont really care.