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
| ### 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.
Thanks for clarifying, I know a separate concern raised was about revising some language so it's helpful to know you're actually concerned the actual meaning is lost. I'm not sure that the words described here go very far to describe the relationship individual adopters may have had with the technology -- including adopting versions that predate this effort.
For simplicity, could that goal of framing history be removed from this section? It doesn't seem to align with the larger section, and separately I know quite a lot was written about the history of efforts -- it seems like this info may make more sense there and not this current post.
There was a problem hiding this comment.
I think this word is critical to describing their relationship to the technology: they laid the groundwork, which gives more credibility to their early blog posts describing their work. The goal is not to delve into the history here, but to point to how the Swift on Android community has long shared info about their work, rather than just code dumps.
I have to say I'm stumped as to why you'd want to take this out, as the earlier concern seemed to be the use of "pioneer," while this new term has no such baggage.
There was a problem hiding this comment.
Is this paragraph the right place to describe their relationship to the technology? And does that word adequately describe it? Separate from word choice, my prior comment was clarifying that it doesn't support the section itself.
I'd suggest we remove this. If there's a story related to the development history of these efforts and adopters that should be told, I think it should live outside the current blog post.
There was a problem hiding this comment.
Yes, it is the right place, as it is a single word that gives credibility to their blog posts that I linked. I think that greatly supports the section, as these aren't just random contributors but those who broke this path.
We are not telling a "story related to the development history" here, merely linking to foundational technical info from a workgroup member and the first company to port Swift to Android. It gives interested readers some background on the technical underpinnings of how this port was built.
There was a problem hiding this comment.
Changed this to "founding contributors" in the latest commit
| 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. 😉
There was a problem hiding this comment.
One challenge of the current heading + some copy in this section is that it's written in oppositional language -- that's not the style of Swift blog, and could benefit from some more positive and direct language. I can open a copy suggestion for this section if helpful.
For example, the first three sentences of the post all have a two-part structure where details are shared, followed by ", but" [...] -- what if instead this section said what it does today and why it matters?
The section also states "We will work with those devs in the coming months to add more info on using their GUI tools with the Swift SDK for Android." -- I think this suggests a much more formal / direct relationship with developers who are currently experimenting with solutions and would benefit from a reframing. Similar to previous feedback, we also avoid forward-looking statements along these lines.
There was a problem hiding this comment.
For example, the first three sentences of the post all have a two-part structure where details are shared, followed by ", but" [...] -- what if instead this section said what it does today and why it matters?
Simple, the Android workgroup has not done much in this area, but a significant minority of potential users appear to consider it critical. The "oppositional" language is intentional: to show that we hear their concerns and are willing to meet them halfway, by suggesting and integrating third-party GUI solutions, but with no plans to work on an official GUI toolkit, unlike the now official Android SDK for business logic that we have developed.
I think it is important to deal honestly with these matters, rather than glossing over them with "positive and direct language" that ignores these perceived holes.
I think this suggests a much more formal / direct relationship with developers who are currently experimenting with solutions and would benefit from a reframing.
I'll change that.
Similar to previous feedback, we also avoid forward-looking statements along these lines.
I think it's unavoidable in a few parts of this blog post, as the whole point of this post is to explain the current status and talk about the future we are working on. Considering this portion is in the vision document that we put together months ago, people can be fairly certain we will be working on this.
Also, this blog does sometimes use "forward-looking" statements, as a quick search turns up phrases like "you can migrate to an upcoming feature" and "These features and bug fixes are included in the upcoming Swift 6.3." Perhaps that is kept to a minimum, only for important exceptions, but I believe this GUI matter is sufficiently important to enough Android users that it is one of those cases.
There was a problem hiding this comment.
Removed the mention of working with GUI devs in the latest commit
|
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. |
|
A few additional things that may be worth adding to the post:
|
|
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. |
|
|
||
| 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.
There was a problem hiding this comment.
Changed this to "the new weather example app he submitted in," which gives him credit and indicates to readers that it is worth perusing, since it came from the main JNI guy.
|
|
||
| [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? 😄
There was a problem hiding this comment.
Slimmed it down to only check one API level at runtime
ktoso
left a comment
ktoso
left a comment
There was a problem hiding this comment.
Looks good, pretty good revision!
|
I've been trying to close the existing GitHub threads / comments before doing a review and opening some additional ones. But the post is getting closer with each revision, thanks for your work on this @finagolfin! Right now there are a number markdown links where the text that's highlighted is quite long; I can open up specific suggestions to change this (easy merges, I hope) but that'd bring the style more in line with other posts. The larger piece of feedback relates to the introductory framing of the post. What if we were to revise the blog post opening so a few timely details are mentioned before addressing some community questions? In particular:
|
No problem with shortening some, so go ahead and list the ones you want, but prefer not to make them too short, as longer links are more clickable on mobile browsers, which is where the vast majority of traffic is these days. I know I still made a couple too short, but only because I didn't see a way to make those larger.
That was intentional: I want serious, engaged contributors who actually read the middle of the post. Unfortunately, a lot of OSS projects get people who say they want to pitch in, then disappear and never do anything: we've gotten a small taste of that with our recent publicity too.
I was going for a "one more thing" Apple keynote effect, 😉 but happy to mention it twice if you think that's better. |
|
I added most of the changes asked for, and teased the new 6.3 SDK snapshots at the top. |
…ks and info Co-authored-by: Marc Prud'hommeaux <[email protected]>
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.