Android vision document

[marcprux]

No description provided.

[ktoso]

This should be moved up into some other section, as JNI support is much more than just "testing support". Perhaps make a new section about language interoperability with Java/Kotlin and put this there

[finagolfin]

I want to spend some time editing and reorganizing this doc, hope to get that done in the coming weeks, after which we can hopefully submit it for review.

[finagolfin]

Got delayed, will have some edits in this week.

[Joannis]

API surface and featureset?

[compnerd]

I'm not sure I fully understand the difference between this and "Shared Business Logic". Ultimately, the fact that you have cross-platform libraries and SDKs is what is enabling the shared business logic. I would consider collapsing the two.

Cross-Platform Libraries and SDKs - Developers can leverage Swift to build libraries and SDKs that can be easily integrated into existing applications, providing a consistent API surface and feature set across platforms. This also allows sharing core business logic, algorithms, and data models across platforms.

[finagolfin]

I agree that it is not a big difference, but there is a difference between companies porting their internal business logic and SDK vendors providing a common externally provided Swift SDK for multiple platforms. This line was likely added to emphasize that that would be supported too.

[Joannis]

Maybe mention cross platform beyond just mobile too?

[compnerd]

I think that the way that the current document is written, it does not feel like a Vision Document.

Vision documents are strategic - describing a direction for where something in the Swift project should head. In this case, we should be describing a direction that the Android support should be going. This should be a roadmap that work/changes can align with.

[compnerd]

I don't think that there is value in this layout. It would make sense in a blog post, but for a vision document, it should focus entirely on the vision.

[compnerd]

Similarly, I don't know if the previous state is useful. The vision isn't really about what the workgroup is seeking to do but rather what the desired state is.

Suggested change

Previously, using Swift for Android development involved relying on unofficial SDKs, custom toolchains, or other third-party solutions. The workgroup seeks to streamline this build process, providing consistent official tooling and improved integration with Android's native APIs and conventions. This should increase Swift's adoption in the broader mobile development space, allowing for greater code sharing between iOS and Android projects and reducing development costs for cross-platform applications.

Android SDK should have a streamlined build process providing consistent official tooling and integration with Android's native APIs and convention.

Once you simplify this, it immediately asks the question: what exactly does this mean. What needs to be streamlined, what tooling is missing, and how does the current status quo not match the Android APIs and conventions?

[compnerd]

This is about Swift and not Kotlin, I don't think that we need to reference that. Is the vision about ongoing work or a concrete state? i.e. is the vision that we do not have a stable point ever and will continually change the behaviour?

[compnerd]

I'm not sure that interleaving this context with the vision is helpful in explaining the vision though it can be useful in explaining the why.

[finagolfin]

I suggest you take a look at the embedded or Wasm vision documents, which similarly explain how those new platforms for Swift work. Since most people don't know how Android works under the seams, this similarly situates the reader.

[compnerd]

I think that the distribution mechanism is not entirely tied indefinitely. While we should encourage dynamic linking, I believe that it should be possible to perform static linking. More importantly, the piece that is core to the message here is that JNI is a requirement for interop.

Suggested change

	C and C++ code are compiled Ahead-Of-Time (AOT) and packaged as native shared libraries- that's how Swift on Android is also distributed- which have to be accessed through the Java Native Interface (JNI), since most Android APIs are only made available through Java.
	Because most Android APIs are only available through Java, applications wishing to use native code must use Java Native Interface (JNI).

But, this feels like an incomplete thought. Okay, so it requires JNI, but what does that mean for the vision?

[finagolfin]

This sentence makes no mention of static or dynamic linking of Swift, both of which we support. Rather, it explains how natively-compiled code like Swift or C has to be distributed on Android, which is sufficiently different from other platforms that run executables that it is worth calling out.

As for how JNI ties into this vision, see the section on bridging below, where we specifically call out this term which we defined and explained here.

[compnerd]

C and C++ code are compiled Ahead-Of-Time (AOT) and packaged as native shared libraries- that's how Swift on Android is also distributed-

To me, that reads as Swift is dynamically linked.

[finagolfin]

I mean, it specifically says it is how it is "distributed," and as you well know, the Android shared library we distribute can either statically or dynamically link the Swift runtime and user code into it.

If you think more precise language is needed here, please suggest some.

[compnerd]

I did suggest something more concretely above :)

[finagolfin]

That was before we discussed why this was written this way, when you simply took out all info about compilation and distribution, therefore there was no info on distribution in your previous suggestion.

Instead, I asked how you think it could be stated more precisely.

[compnerd]

The only change I would recommend is that rather than "best practices ... will be provided" should be more "Documentation covering best practices for ... need to be provided to allow users to easily integrate multiple languages.".

[compnerd]

I think that we should extend this further to say that we want to have a consistent NDK requirements across host platforms.

[finagolfin]

Sure, makes sense

[compnerd]

I'm not sure about the call outs to external projects. @shahmishal might be able to help shed some light on this.

[finagolfin]

Both are OSS, so I think it should be fine, as people want to see concrete examples.

[compnerd]

Sure, but we have shied away from referring to OSS projects previously as well.

[finagolfin]

OK, up to Mishal to clarify the guidelines on that then.

[compnerd]

I think that this is the wrong way to approach this. While we don't believe that a UIKit replacement needs to be built, the community is free to build something like that.

[finagolfin]

Of course, that is specifically mentioned above. This is specifically saying

1. the workgroup will not work on a GUI toolkit
2. No one GUI toolkit will ever be made the "official recommendation"

[compnerd]

I think that for

1. I don't think that the vision document is a statement of work for the workgroup
2. this definitely can be articulated better

[finagolfin]

1. It isn't, here at least, we are explicitly saying what we won't do. 😜 As I commented above, I think it is good for us as the Android workgroup to explicitly draw some lines on the work we will/won't do, at least for a few important topics like this.
2. See the section above: "There will not be a single official UI framework, instead we will acknowledge and support various approaches"

[compnerd]

1. I'm merely saying that we don't call out that we are the ones doing the work. Clearly stating what we want to see (both in the positive and negative) is the point. I think that even if they are smaller topics, that is perfectly reasonable. If we have a vision of how some parts should work and not others, we can start there. This doesn't need to be set fully in stone and can evolve as well.

2. I think that the quote on its own is what I am asking for - just simplify to that so it reads clearly.

[compnerd]

I'm not sure where this comes from. There is no mention of anything even remotely in this direction in the document, so it feels like it comes from left-field. Is this something that has come up in the context of the Swift Java?

[finagolfin]

In general, people assume that new Android languages will compile to JVM bytecode, like Kotlin does and we explained above, "Most apps are written in Java or Kotlin and run on the Android RunTime (ART), distributed as bytecode and either compiled to machine code when installed or Just-In-Time (JIT) when run."

This bullet point is emphasizing that in addition to what we wrote above, ie "C and C++ code are compiled Ahead-Of-Time (AOT) and packaged as native shared libraries- that's how Swift on Android is also distributed," we will not be pursuing the bytecode approach also, which eg Max suggested on the forums years ago.

[compnerd]

Interesting. I didn't know that had been proposed. Perhaps it is better to extract that into a foreword or separate section that explains how Android works and Swift interacts with that environment? More specifically, I think that what is being suggested is: the vision is to not change the fundamentals of Swift, which is a by design an AoT language and we do not intend to change that to a VM based language.

If that is the intent of this, I think that this is something again to be very clear on, because it is very critical that users understand this. More than that, I don't think that it should be a side note in the negative form. That should be pretty clearly stated upfront.

To be clear, I am not making a judgement on the direction, rather I'm just trying to ensure that the vision is clearly shared.

[finagolfin]

We do clearly state that Swift will be built and distributed like C/C++ in the section above, but added this note at the end to shut the door on the workgroup trying the bytecode approach too.

I don't think this is so important that it needs to be called out in a "separate section," as most app devs don't much care about AoT vs bytecode. For general understanding of readers, we added the explainer above, and for the small minority who may want or expect bytecode too, we added this note.

[compnerd]

I think that we are in agreement then. I don't think that it needs a separate section - it just needs to be clearly stated as a starting point.

[finagolfin]

@compnerd and @swiftlang/platform-steering-group, we will try to integrate this feedback into the doc, but on larger statements like this, not sure how to respond:

"I think that the way that the current document is written, it does not feel like a Vision Document. Vision documents are strategic - describing a direction for where something in the Swift project should head. In this case, we should be describing a direction that the Android support should be going. This should be a roadmap that work/changes can align with."

Android is unusual in that it has been worked on already for eleven years, so the "vision" here is really how to complete that journey we started long ago, unlike much newer or unusual platforms like embedded or Wasm that needed more of a technical strategy in their vision docs.

Most of this doc does consist of the "direction that the Android support should be going," which for a mature platform like Android means listing areas where further work is needed, as we do here, and even a few where we will not be going. Our current project board pretty much already aligns with this doc, and once we know more about areas like integrating Gradle mentioned here, they will be added to that board too.

For a mature and very large platform like Android further integrating a mature language like Swift, a vision doc is mostly about defining scope, ie what we think should and shouldn't be done, as the work mostly involves a bunch of integration, not really a big new technical strategy. I think we have done that scoping here, but I'm happy to hear concrete suggestions on any scoping we can do better.