Add Android blog post answering common questions and sharing more links and info #1249
Conversation
finagolfin
requested review from
a team,
davelester,
shahmishal,
timsneath and
tkremenek
as code owners
| ### Sharing Logic Versus Sharing UI | ||
|
|
||
| A common concern is that we do not provide a cross-platform GUI toolkit. As we | ||
| write in [our draft vision document](https://github.com/swiftlang/swift-evolution/blob/807b844be42db582e434d1667fc907ae7a7a8775/visions/android.md), |
There was a problem hiding this comment.
| write in [our draft vision document](https://github.com/swiftlang/swift-evolution/blob/807b844be42db582e434d1667fc907ae7a7a8775/visions/android.md), | |
| write in [our draft vision document](https://github.com/swiftlang/swift-evolution/pull/2946/files), |
Let's point to the vision document via PR url.
There was a problem hiding this comment.
I don't have a strong preference, but I linked it this way because it is better formatted for reading. Is there any reason you prefer this other link?
There was a problem hiding this comment.
Readers will be directed to the most recent version of the Vision document as it is updated in the PR.
There was a problem hiding this comment.
OK, I am aware that I'm linking to a particular commit, but I don't see a way to show the more reader-friendly view of the pull itself.
Since this pull hasn't been updated in a while, how about we keep this commit link, then I will update the blog post later once that vision pull has been merged? Once it is in the swift-evolution repo, it is easy to link to a constantly updated version that is reader-friendly. This commit link also should be fine because we don't anticipate substantive changes to the vision pull, only stylistic and minor edits from here on out.
| ### Diving in | ||
|
|
||
| Finally, we intend to bring you interviews and information from those using Swift | ||
| on Android already, as pioneering companies like [Readdle](https://readdle.com/blog/swift-for-android-our-experience-and-tools) |
There was a problem hiding this comment.
| on Android already, as pioneering companies like [Readdle](https://readdle.com/blog/swift-for-android-our-experience-and-tools) | |
| available. Early Swift on Android adoptors [Readdle](https://readdle.com/blog/swift-for-android-our-experience-and-tools) |
There was a problem hiding this comment.
Pioneers is better than "early Swift adopters"
There was a problem hiding this comment.
Changed this to path-breaker instead
There was a problem hiding this comment.
"path-breaker" is not a term I have heard before. How about "Trailblazing"?
There was a problem hiding this comment.
Is there a particular idea you hope to communicate beyond the fact that these organizations were early to adopt Swift on Android? I wonder if there's a more direct and accessible way to say that.
If it's accurate, perhaps we could say they are "among the earliest adopters" if that's more engaging?
Given that the Swift blog is a channel of the project, I'd look for ways to avoid characterizing individuals or organizations. We've been discussing specific terms / accolades, but being straightforward would be preferable.
BTW I also think there are additional opportunities in the post to have more personality / liveliness, rather than trying to find an alternative adjective to describe these specific adopters.
There was a problem hiding this comment.
Is there a particular idea you hope to communicate beyond the fact that these organizations were early to adopt Swift on Android?
Yes, they did not "adopt" Swift on Android, as there was nothing to adopt, they laid the path on which we all tread on Android today.
This isn't about personality: it is about accurately crediting these path-breaking founders of this effort! 🥲
| into editors like [Visual Studio Code](/blog/gsoc-2025-showcase-swiftly-support-in-vscode/), | ||
| Android Studio, and [CodeEdit](https://www.codeedit.app/), another issue on our board. | ||
|
|
||
| ### Sharing Logic Versus Sharing UI |
There was a problem hiding this comment.
| ### Sharing Logic Versus Sharing UI | |
| ## Cross-platform code sharing using Swift |
There was a problem hiding this comment.
I'd suggest a slight reframing of this section to focus on the value of cross-platform code sharing in Swift. The mention of GUI toolkits is useful, but I think it'd be more natural to mention that after explaining the value of cross-platform code sharing with Swift.
There was a problem hiding this comment.
Do we have a few concise examples of the type of business logic that you'd commonly see shared between platforms? It'd be great if we could outline a few examples in one paragraph, before mentioning cross-platform GUIs in a second paragraph.
There was a problem hiding this comment.
Again disagree with the heading change, but good point on the business logic example, will add that.
There was a problem hiding this comment.
I agree that putting some code in this post would be nice, the problem is that almost anything we add will be nit-picked. Instead, I added some text explicitly stating that Swift is for business logic on Android, and that the GUI tools linked have not been validated by us, though we intend to work with them going forward.
There was a problem hiding this comment.
Added a clause on the value of sharing code across platforms but kept the heading, which describes this section well. Added some code in a different section, though may be too much code now. 😉
|
Thanks for incorporating the feedback, looks okey now |
|
@davelester, made most of your suggested changes: the only vein of disagreement was my attempt to use physical or historical words like "snowballing" instead of "expanding" or "pioneers" instead of "early Swift adopters." 🙄 While a case can be made that the more generic terms are better known, I don't think the physical/historical terms I chose are much less known, so I prefer the more concrete prose. |
| category: "Developer Tools" | ||
| --- | ||
|
|
||
| Since the announcement of [the preview Swift SDK for Android last month](/blog/nightly-swift-sdk-for-android/), |
There was a problem hiding this comment.
| Since the announcement of [the preview Swift SDK for Android last month](/blog/nightly-swift-sdk-for-android/), | |
| Since the announcement of [the preview Swift SDK for Android](/blog/nightly-swift-sdk-for-android/), |
There was a problem hiding this comment.
Changed this to months ago
|
A few additional things that may be worth adding to the post:
|
…ks and info Co-authored-by: Marc Prud'hommeaux <[email protected]>
|
Updated this with most everything discussed, including a new code sample too. Three editor's notes remain for external links that are still being worked on, that we hope to get in before this post is published, but this post itself is ready for final review. I have changed the tentative publishing date to Thursday morning PST, which should give us enough time to finish up review and those last few tasks, or push it to Friday if needed. @compnerd, let me know if I should link the 6.3 Windows toolchain snapshots too, ie if they include the Android SDKs also. |
| and was [interviewed by Swift Toolkit last month](https://www.swifttoolkit.dev/posts/dc-pier). | ||
|
|
||
| A [community member recently contributed an example app](https://github.com/swiftlang/swift-android-examples/pull/24) | ||
| that builds C++ using CMake and links it with Swift, using Swift's automated JNI bridging |
There was a problem hiding this comment.
| that builds C++ using CMake and links it with Swift, using Swift's automated JNI bridging | |
| that builds C++ using CMake and links it with Swift, using [swift-java](https://github.com/swiftlang/swift-java) to automate the Java interop layer generation. |
Maybe like this? We should link to the project, not just describe it
There was a problem hiding this comment.
Already linked above 😄
|
|
||
| The [`jextract` tool gained a JNI mode this summer](/blog/gsoc-2025-showcase-swift-java/): | ||
| you can now watch its author Mads Odgaard's [Server Side Swift Conference talk from a couple months ago](https://www.youtube.com/watch?v=tOH6V1IvTAc) | ||
| and try out [his new weather example app in the Android examples repository]( |
There was a problem hiding this comment.
| and try out [his new weather example app in the Android examples repository]( | |
| and try out [the new weather example app in the Android examples repository]( |
It's true that it's "his" example, but more than that, it is a Swift project example, so I'd phrase it as "the example"
There was a problem hiding this comment.
He wrote it, so giving him credit, but don't really care 🤷♂️
There was a problem hiding this comment.
+1 to @ktoso's suggestion, a revision to say "the" -- by nature of being included in the /swiftlang GitHub org, the example app is now part of the community project.
|
|
||
| [An Android workflow](https://github.com/swiftlang/github-workflows/pull/172) was | ||
| added to the official Swift workflows for GitHub months ago, allowing you to easily | ||
| try building your Swift packages with the Swift SDK for Android, and work is underway to let you |
There was a problem hiding this comment.
| try building your Swift packages with the Swift SDK for Android, and work is underway to let you | |
| build your Swift packages with the Swift SDK for Android, and work is underway to let you |
No need for the "try", makes it sound like it'll fail 😅
| } | ||
| } | ||
| ``` | ||
| (editor: should we slim this down?) |
There was a problem hiding this comment.
Maybe just one "if..." is enough?
There was a problem hiding this comment.
Heh, too many API levels checked? 😄
| @available(Android 27, *) | ||
| func hello27() { | ||
| print("Hello, world!") | ||
| } |
There was a problem hiding this comment.
It's probably enough to just showcase one method to get the point across
ktoso
left a comment
ktoso
left a comment
There was a problem hiding this comment.
Looks good, pretty good revision!
5 participants
The Android workgroup has been monitoring aggregators and other forums and seeing more detailed questions about the new SDK snapshots. Marc and I put together this post with more info, with input from others in the workgroup and long-time Swift on Android users, and the SWWG asked us to put it up for public review now.