https://kotlinlang.org logo
Join Slack
Powered by
Will Apple let KMM succeed? Effectively, Multiplat...
# multiplatform
i
Will Apple let KMM succeed? Effectively, Multiplatform Compose and KMM will make iOS Developers, XCode or Swift obsolete. So, what is in it for them? And what guarantees the Kotlin Multiplatform approach will be possible to be used for development in 2-3 years?
c
I don't feel it makes it obselete. Thats a similar argument to saying Ionic / React Native / Flutter makes swift obsolete. There are a range of different ways to build apps, each serving different use cases
l
I’d imagine anti-competition laws will be a major part of this. They’ve been losing a lot in the EU with USB-C replacing lightning and with sideloading in iOS 17.
s
You could see KMM/KMP just as a way to write iOS frameworks. Native code is produced. I don't think that Apple has any qualms about that as long as they get their 30% 😀
l
I would think that KMM will go further than React Native/Flutter just because of the better native interaction. Our major issue with Flutter on our team is difficulty interacting with native (and debugging method channel calls), as well as performance of this approach. By directly calling into Obj-C code, it reduces Swift’s advantage of first-party support. There’s still going to be certain advantages to Swift, but less than now.
c
What Apple cares about is that people are installing (or more importantly, purchasing) apps and in-app-purchases from their app store. They don’t care as much about the tech used to implement it, as long as folks are still installing apps through the App Store.
j
You're still forced to use macOS & xcode & their app store currently
i
@Ciaran Sloan It is not the same, because these frameworks never managed to achieve same performance as the native approach. Also, in the end you still had to write code for native APIs yourself and communicate via some sort of Channel to the wrappers around it, something that KMM delivers out of the box. So in the end, if I can write UI, access native APIs and have the same performance as using Swift/SwiftUi/UIKit, why would I ever do it, if I can cover everything with Kotlin + Jetpack Compose (Which is also getting Multiplatform support)
l
Not sure that Kotlin/Compose will ever fully replace Swift/SwiftUI, mainly due to third party support. Our Flutter app often suffers from third party companies refusing to provide support, since they want to focus on supporting Swift.
j
Will Apple let KMM succeed?
I'm curious on your thoughts of what Apple could do to stop it from succeeding/progressing?
c
Again, Apple as a business cares that apps are being sold. They have a strict review process to ensure that apps are meeting minimum levels of quality (not crashing on startup, for example) and privacy. If a non-Apple tech stack is able to deliver apps that meet that level of quality, why should they care? Apple cares much more about its end users than the tech used to make the apps, because that’s how they make money. They aren’t making money from Swift (it’s open source) or from Developer Accounts (the revenue is trivial in comparison to app sales). In fact, considering how much they must spend on R&D for the language and tooling, they’re losing a significant amount of money on that stuff alone. Without the App Store sales, there are not iOS apps anyway. So to some degree, they should actually be incentivized to allow such frameworks as Flutter, React Native, or Compose Multiplatform to thrive, as it effectively gives them higher margins on their products. As as others have noted, Compose MPP is nothing new. Flutter, React Native, and other frameworks have been publishing apps for years and Apple has (to my knowledge) never tried to suppress the distribution of those apps or technologies
l
I’m curious on your thoughts of what Apple could do to stop it from succeeding/progressing?
Their easiest course of action would be rejecting apps, but not sure if they will want to risk attention from the EU or drive away devs.
i
@Casey Brooks A lot of developers need Macbooks to build iOS Apps. Imagine having a single iMac as your build server and writing everything else in KMM. The loss of the control they had over their ecosystem is already one thing that they probably don’t like and it is a loss of revenue for them, and as you said, money is everything for Apple, I don’t think this will sit well with them
j
Imagine having a single iMac as your build server and writing everything else in KMM.
I'm not sure I follow this, you still invested/bought into the iMac, just like you would've invested/bought into some kind of Macbook?
c
And that’s why I don’t think they would be opposed to alternative frameworks. In the end, if you want to release an iOS app, you do still need to pay for Apple hardware. These frameworks need to play by the same rules as everyone else, and they’re pushing the burden of work onto them. If they really didn’t want anyone else compiling apps for iPhones, they wouldn’t have open-sourced Swift so everyone can figure out what the ABIs should look like
i
@Josh Eldridge You would need only one iMac per team/company vs. a MacBook for every iOS developer
j
What about local development/testing/running?
l
You’ll still have to have devs testing on iOS, to make sure there’s not platform specific issues, and devs working on native integration will have to have a mac for local testing. The cross-platform promise of testing on android and it works on iOS rarely works in my experience.
i
Local Development is done in Jetpack Compose Multiplatform (UI) + Kotlin. Testing / Running is done with CI/CD on the single iMac. If you can write a single codebase for two platforms and it works on Android, it will also work on iOS
c
What about local development
You cannot test KMM apps n iOS except on a Mac simulator or physical iPhone. You can unit-test the common code without it, but it would be pretty bad practice to release an app where you only unit test the individual pieces without doing full integration tests on the physical hardware. This is true for both Android and iOS, BTW
i
Testing native APIs like Camera APIs would anyways not be done by you (or shouldn’t) because you should expect third-party APIs to be tested
l
If you can write a single codebase for two platforms and it works on Android, it will also work on iOS
As someone with Flutter experience, this rarely holds outside of the simplest possible apps. You have to have a lot of trust in the libraries and know every possible limitation.
c
And thinking in terms of money again, Apple doesn’t care about apps developed by 1 person as much as it does larger corporate apps/teams, because larger companies generate significantly more revenue. If you as an individual want to develop and release a KMM app without developing/testing on Apple hardware, that’s fine. But no major company in their right mind would do that, they would pay for their devs to have Macs
i
@Casey Brooks You can have integration tests running on the build server, as I said.
j
There is no way you're getting away from doing some kind of local simulator testing, you could have all the CI/CD unit tests/integration tests and even instrumented tests you want, but the devs still need to be able to run the app locally.
c
Right, so Apple still gets their cut from you buying that build server
i
Yep and it is one machine vs potentially 20
Or insert x to the vs number
c
But let’s just put some actual numbers to that. Let’s say you have a team of 20 iOS developers (which is a very, very large dev team, BTW). An app with a team of that scale likely has 100k-1M monthly users. For simple numbers, we’ll say the app costs $0.99 to buy, no subscription. That’s still upward of $30k-$300k generated for Apple, and will continue to increase over the life of that company developing the app, and this is just pure profit for Apple. In contrast, the revenue from selling macs to that team is roughly $60k (20 devs * $3k per macbook), but is a fixed 1-time payment. Big numbers, yes, but considering the actual cost of the hardware, the profit is considerably less.
i
@Casey Brooks Apple would completely lose control over their developer ecosystem, which knowing Apple, is not something they will let happen voluntarily. iOS Apps have been written before Flutter, Cordova and would be written without these frameworks as well
It is not like iOS gets extra reach because of Flutter
Any company not writing a native iOS App with these numbers would be insane to not write it
l
A team making that much money and hiring 20 devs for iOS likely can’t rely on a single machine running its whole testing suite. We’ve seen many issues slip by because an iPhone 12 on iOS 15.4 allocates memory in a slightly different way than an iPad mini on 14.1, or something like that.
r
KMM is certainly not a threat to Apple right now, or for the foreseeable future. If anything, it helps them because it makes Android developers more likely to build an iOS app. It doesn't cut into Apple's revenue stream in any way, because to build and release an iOS app with kMM, you need a Mac with XCode, you need an Apple Developer account, and you need to release it on the official Apple App Store. In that respect, it's indistinguishable from a normal iOS app. A lot would need to change to change that calculus. If/when KMM fully supports Swift, then it might be possible to replace all SwiftUI code (and other platform-specific Swift code) with Kotlin. But you still want to have something to preview your SwiftUI views, run the app on a simulator or device, etc. Is JetBrains going to replace all of that? Doesn't seem worth it to me. And even if they do, it doesn't change the fact that app releases, and all associated revenue, still have to go through the App Store.
l
I’m currently (supposed to be) debugging a crash that happens on all iPad minis, iPhone 12 Pro max and iPhone X devices we’ve tested, but no other model. Even using KMM for this, we still have to purchase several more devices because my SE is useless in testing this.
p
I would say, let's get there first and see what happens. It will be interesting/funny, seeing Apple rejecting Apps not built with their stack.
l
When mentioning the App Store, keep in mind that iOS 17 is supposed to allow sideloading (at least in the EU). Will we see new app stores come out of this? Possibly something similar to Aurora.
r
The one thing I could see them getting pissy about is that it works the other direction: it could make it more likely for pure iOS devs to learn Kotlin and make multiplatform versions of their apps that are only on iOS. How likely is that to happen, and how likely is Apple to make a stink about it? Who knows. They can be unpredictable.
j
Also would you really rely on a full team of devs that have never once ran the app themselves? You can do all the CI/CD testing in the world but nothing replaces actually being able to run the app while developing, and everyone isn't going to remote into the build server to try and run the app in some emulator from there.
p
They should create a swift multiplatform framework, for the iOS developers to not going KMM/KMP lol
c
And one more point I’ll throw out there: it’s very common when a new piece of tech (X) comes out for everyone to say “is tech Y dead?“. I’ve been developing long enough that I can confidently say the answer is no, 100% of the time. Tech Y may be great, but companies have already invested millions of dollars into tech X, and will always need to continue supporting that tech. There are still many companies using AngularJS, despite it having actually been “replaced” by Angular 2+. COBOL is still widely used in large, old, enterprise and government systems. Engineers still write code in FORTRAN. No technology is ever completely dead, ever.
l
Also would you really rely on a full team of devs that have never once ran the app themselves?
As someone currently sitting next to 2 macbooks and 3 iOS devices, I can confidently say I don’t trust code that works on my iPhone SE to work on an iPhone 12 or an iPad, much less code I’ve tested only on Android. I typically work on much lower-level code, so that has an effect.
k
Also let's face it Swift/SwiftUI is also amazing and always going to be first class citizen in the apple ecosystem (until superseded by another apple offering) so it's not going anywhere anytime soon. I haven't seen any real developer who would get far without being able to run the app during development on actual physical devices 😉
l
That’s not to say that there’s not value in sharing code. I’m not going to miss the days when I’d finish debugging a memory issue on Android, to then have to check that it wasn’t in our parallel iOS codebase too, then apply a (possibly slightly different) fix after debugging that. Sharing code makes it more likely that fixes will carry over, but far from guarantees it.
k
It depends on what you are working on but once you are using a lot of native apis you'll end up with different problems on the different platforms. We primarily use KMM so that we can share the business domain layer across the platform ensuring getter alignment between platforms.
i
@Krisztian Balla @Casey Brooks You can run the app, but on your Android device. You set up integration /UI tests for checking behaviour on a wide scope of devices -> it will catch any kind of weird behaviour on different devices/ OS versions, much rather than a single developer running an app on his single device. If you are not confident that your multiplatform approach runs the same on Android and iOS and still think you need to run both manually to check if they work properly, then why would you be using this cross platform framework anyways?
Also @Casey Brooks as mentioned, iOS apps don’t exist because of cross-platform frameworks, it is the other way around.
p
It is funny the whole tech Y will kill tech X. If you visit a rust forum, they saying rust will kill all the languages. I still have yet to see a dead tech like Casey pointed out.
i
It is not about killing a technology, I don’t claim one is better than the other. It is about a rational examination of profitability for the parties involved, and if Apple showed anything in their existence from day 1 is that they want to control everything. Rolling the dice on in what extent this will happen by going all in on something like KMM still feels like the wrong decision and being too risky (involving extra cost)
Besides that, tech Y killing tech X is still a very real thing. Imagine starting a Cordova App in 2023 and the percentage of people who would now decide to do that.
l
Not sure to what degree Apple will risk that. Rejecting Hey from the app store got the ball rolling on the EU forcing sideloading.
I was less interested in the potential of the EU intervening if Apple tries to reject apps made with cross-platform frameworks until the USB-C and sideloading rulings. It will be interesting to see how this affects Apple users in the US.
p
I mean, there have been cases of tech Y killing tech X, is just that when tech X is well established, it is less likely to happen. Cordova really never made it. But I don't see a risk in this case. Not allowing native code to run would turn down the whole gaming framework industry, which is a c++ dominated territory. In fact what's different from kmp and a gaming framework. In any case, let's get there first and see what happens later.
It would be funny to watch Tim Cook announcing the ban on cross platform Apps on the store. Because the cross frameworks perform better than Swift lol. They definitely find a better excuse, like security risk or something else. But I doubt it will ever happen.
u
Why would apple care about KMM enought to ban it, when it doesn't care about its own developers by having them to use XCode and all that horrible terrible toolchain and developer experience. To bump a language level you need to bump xcode level (2gig download, whole IDE, why?), and to bump xcode level you possibly need to bump OS level (you serious?). And after whole day of updating, you try to build your project ...and.. it doesn't work So now you spend two days downgrading your OS and reverting all back Vs. changing a char in gradle config and hitting build .. lmao
I like swift, certainly up to par with kotlin but their tools are 5 years behind android
l
XCUITest showed me that Apple has a long way to go with tooling...
j
I am convinced that whoever made xcode has never used a good IDE in their life
l
XCode 14 seems to have removed all error output for custom build scripts. Makes finding errors in my Kotlin code fun.
u
Actually few months ago I started to help our ios team, thinking, I've seen swift, looks nice, and they have their coroutines and reactive framework, reacctive ui and it's all mobile apps, so same architectures apply but the day to day is so much worse and I don't even want to tell the colleagues how bad they got it, better they don't know
and now jetbrains sunsetting AppCode, I'm super pissed
l
Our iOS guy was so happy to use VSCode, since it was better than XCode. Had to hide IntelliJ from him so he wouldn't be as disappointed in XCode.
u
I mean, now I've seen multiple screen shares of ios guys asking me stuff, and they way they use the IDE .. its basically a notepad with color syntax, so sad
VSCODE works for ios?????
l
This was for another project. My boss wanted us to branch out from our typical platforms for a bit.
j
I am in the same boat as you and had to start helping with the iOS side of our app and xcode alone has made my job miserable. I shouldn't get different outputs running a build multiple times in a row
u
haven't tried it yet, but I THINK we still can use AppCode for the year, and after that I HOPE they'll opensource it or something, so it can be kept up with xcode versions, otherwise its irrelevant after a year
-- and to finish, the solution to the updating issue is, learned from other companies, to never update when it gets out if youre a professional buy a separate machine, where this all gets tested, and only when working, green light the team to update so, in the end, you paid them more money
what if you work on multiple projects? then go fuck yourself I guess 😄 buy another machine
tldr; I'm sad/angry, since macOS is the best, and new macbook pros are amazing, but full time ios development is a pain, unless you don't know otherwise
which also doubly makes me careful with KMM, because, it will 99,99% work when working on android
and if it fails, it fails on ios, and now you'll introduce cryptic errors into their already cryptic world, and they'll look at you to fix it, since you, the android guy, pushes it on them
but, it will be made up by them kissing your feet, for giving them the opportunity to use intellij & gradle, and have debugger work lol
p
I think that pain won't change anytime soon. Going back to the original comment, games are still number 1 reason consumers download an App and most of them are built with crooss-platform. Not to mention that if webassembly get the support is expected. There won't be a need for native development no more
u
well, yea, it all hinges on how good kotlin/native is
p
Right
u
arguably making games work is easier since c++ is unmanaged runtime etc.
making both managed & unmanaged, uff that's steep
I mean there is 30years invested into JVM development, i.e. making multiplatform work
p
The good thing about wasm, is that they are shipping a garbage collection with it, so perhaps the Kotlin Native runtime/gc is not even needed
u
and we're now expecting to kotlin native 1.0 stable have it all work .. I don't know..feels premature imo
p
I am sure it works but definitely is going to be a lot of room for improvement.
u
sometimes I wish android went for some other language, they didn't really need a JVM
and now it's all ARM anyways
and afaik JVM's main point was multiplatform, which is not leveraged
p
Apple never liked the JVM either
u
to their point, not sure it makes sense on mobile anyways, especially in the beginnig when hardware was weak
p
Right!
u
but then again, objc is horrible, c++ is for aliens, interpreted languages are a no go .. different world back then
p
I put all my bets on webassembly. It will be the easiest/best crooss-platform solution
u
how does that work? does it need a browser to execute it?
p
Yes
u
so basically what electron does for desktop?
p
I am not familiar with electron not sure what it does. In the case of webassembly, it is the same as if you build a webapp. Is just that, the performance is 30-50% better. No HTML document or JavaScript parsing. It renders directly on a native canvas.
u
yes but who executes the code, webview?
c
does it need a browser to execute [wasm]?
Actually no, wasm is simply a binary format. There are wasm runtimes that can be embedded into other applications without needing a browser. It’s really not all that different from any other application binary format. The part of wasm that makes it so interesting (and potentially revolutionary) is just the fact that it is already included in browsers, which effectively makes the browser something more like an OS than just an HTML renderer. All the major browsers have agreed to support it, so it effectively gives you an “OS” that works independent of the physical hardware it’s running on, and works on all devices/host OSs
Conceptually, wasm isnt all that different from Java 
.class
files and the JVM runtime. It’s just a bit lower level, more optimized for security, and distributed automatically in your browser. But I’m personally holding back my hype for now. Remember, browsers actually used to be able to run Java applets, too…
u
but how would it run on ios if not in browser/webview? does ios need to support it natively? or what is the vector for mobile, where is the VM? 😄
l
Will webasm runtimes be exempt from JIT rules on iOS, or will it AOT?
p
In the case of iOS it most likely would be through the browser
c
The vector for mobile is currently through the browser. I personally don’t see wasm being natively supported anytime soon. wasm certainly has the potential to be very revolutionary, but I’ve learned to be skeptical of “revolutionary tech” until i actually see it taking over, and in the mobile world that would take both Apple and Google committing to running wasm as an alternative format to APK/AABs and IPAs. That’s not to say that it won’t, it definitely seems to have a lot of momentum behind it. But I’m not going to hold my breath for it on other platforms. Native wasm apps is a much bigger problem to solve than just running it in mobile browsers
p
The good thing I see about wasm, is that, even if Apple doesn't provide the required support for safari. It won't stop users installing Chrome
So they won't have other option than then banning chrome, Mozilla and edge from their store. So they are basically in checkmate
But I mean we are assuming Apple don't like multiplatform and we may be wrong. Cross platform takes a big load off their work. We gotta see how all these techs perform when they mature, then have this talk again
u
okay so in order to get native wasm, you'd need a native VM implemented per platform, so basically java world just different flavor
p
Basically a VM spec, in which the bigger browser/os makers agree upon. But, yeah, a lot of hype around it. You can get a taste of it already, with compose multi platform, enabling IR in the JS target. The performance is not terrible and that is just using wasm to bind the skia canvas function call, all other Kotlin code is compuled to JavaScript. Once the Kotlin code compiles directly to wasm, it would be way much better
j
Coming back to this conversation because I just remembered this, how are you going to do the iOS specific development on a Windows machine anyways? You don't actually get to use the imports when not on macOS
l
I would imagine if there was enough use case, JB could have it read the klib for macos platform.
p
The reality is, it has an impact on Apple, not sure if good or bad but cross platform impact them. Otherwise they wouldn't force WebKit usage or other similar rules
951 Views
Open in Slack
PreviousNext
Powered by