You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this post I want to describe you our reasons to suspend our plans on working on a native iOS version of alphaTab. After so much time invested, this feels like a sad decision but I hope we will benefit instead of nice features in alphaTab with the time invested differently than trying to get this solution working.
No access to a macOS and iOS development environment
As many of you know, Apple only officially supports developing on macOS for iOS. I do not own any Apple devices which would allow me to not only develop but also test alphaTab for iOS. This already makes it a challenge to provide an iOS version.
Our initial plan was to develop a version using Kotlin/Native targeting Windows and Linux to develop and test a native version of alpahTab and then target iOS rather blindly relying on the community to give feedback. Developing really an iOS UI control, integration and examples feels impossible to be done properly following that path.
The goal to target iOS via this path turned out to be way to time consuming and risky.
Complexity of Kotlin/Native
Our initial plan was to develop a version using Kotlin/Native. Kotlin Multiplatform was an experimental technology for quite a long time becoming stable only recently.
We had to wait for a lot of bugfixes over time because it was simply not usable for our needs. With the latest releases I was able to get a first Windows Native version compiled and 591/599 tests running but the general conclusion is:
The overall tooling in Kotlin/Native is very bad when it comes to handling dependencies (e.g. consuming alphaSkia).
The tests show a significantly worse performance than any other target we have.
The failing tests indicate some more bugs in Kotlin/Native
Compared to all other targets we have, the Native version feels very very experimental and would rather backfire than bring a real benefit to the market.
Future outlook
Even though I have invested a lot of time and energy getting that far, I think it is still a long way to get a reliable iOS version via Kotlin/Native even if we would have a macOS and iOS hardware available.
I have decided to better invest my time into developing more features for alphaTab and maybe add some other non-native targets we could support easier (e.g. Python and Go).
My hope is that .net with the NativeAOT pipeline will improve and allow us to target iOS via a .net compilation path which would need a lot less effort.
Hello alphaTabbers.
In this post I want to describe you our reasons to suspend our plans on working on a native iOS version of alphaTab. After so much time invested, this feels like a sad decision but I hope we will benefit instead of nice features in alphaTab with the time invested differently than trying to get this solution working.
No access to a macOS and iOS development environment
As many of you know, Apple only officially supports developing on macOS for iOS. I do not own any Apple devices which would allow me to not only develop but also test alphaTab for iOS. This already makes it a challenge to provide an iOS version.
Our initial plan was to develop a version using Kotlin/Native targeting Windows and Linux to develop and test a native version of alpahTab and then target iOS rather blindly relying on the community to give feedback. Developing really an iOS UI control, integration and examples feels impossible to be done properly following that path.
The goal to target iOS via this path turned out to be way to time consuming and risky.
Complexity of Kotlin/Native
Our initial plan was to develop a version using Kotlin/Native. Kotlin Multiplatform was an experimental technology for quite a long time becoming stable only recently.
We had to wait for a lot of bugfixes over time because it was simply not usable for our needs. With the latest releases I was able to get a first Windows Native version compiled and 591/599 tests running but the general conclusion is:
Compared to all other targets we have, the Native version feels very very experimental and would rather backfire than bring a real benefit to the market.
Future outlook
Even though I have invested a lot of time and energy getting that far, I think it is still a long way to get a reliable iOS version via Kotlin/Native even if we would have a macOS and iOS hardware available.
I have decided to better invest my time into developing more features for alphaTab and maybe add some other non-native targets we could support easier (e.g. Python and Go).
My hope is that .net with the NativeAOT pipeline will improve and allow us to target iOS via a .net compilation path which would need a lot less effort.
Feel free to discuss the topic further here:
#1332
The text was updated successfully, but these errors were encountered: