Add Android blog post answering common questions and sharing more links and info

[finagolfin]

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.

[shahmishal]

Suggested change

	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.

[finagolfin]

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?

[shahmishal]

Readers will be directed to the most recent version of the Vision document as it is updated in the PR.

[finagolfin]

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.

[davelester]

Suggested change

	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)

[finagolfin]

Pioneers is better than "early Swift adopters"

[finagolfin]

Changed this to path-breaker instead

[marcprux]

"path-breaker" is not a term I have heard before. How about "Trailblazing"?

[finagolfin]

Same thing 😄

[davelester]

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.

[finagolfin]

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.

[davelester]

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.

[finagolfin]

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.

[finagolfin]

Changed this to "founding contributors" in the latest commit

[davelester]

Suggested change

	### Sharing Logic Versus Sharing UI
	## Cross-platform code sharing using Swift

[davelester]

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.

[davelester]

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.

[finagolfin]

Again disagree with the heading change, but good point on the business logic example, will add that.

[finagolfin]

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.

[finagolfin]

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. 😉

[davelester]

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.

[finagolfin]

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.

[finagolfin]

Removed the mention of working with GUI devs in the latest commit

[ktoso]

Thanks for incorporating the feedback, looks okey now

[finagolfin]

@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.

[davelester]

A few additional things that may be worth adding to the post:

• Announce 6.3 SDK snapshots of the Swift SDK for Android
• New contributors call on December 20th https://forums.swift.org/t/swift-on-android-new-contributors-call/83729

[finagolfin]

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.

[ktoso]

Suggested change

	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"

[finagolfin]

He wrote it, so giving him credit, but don't really care 🤷‍♂️

[davelester]

+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.

[finagolfin]

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.

[ktoso]

Suggested change

	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 😅

[finagolfin]

It might, see #1198

[ktoso]

Maybe just one "if..." is enough?

[finagolfin]

Heh, too many API levels checked? 😄

[finagolfin]

Slimmed it down to only check one API level at runtime

[ktoso]

Looks good, pretty good revision!

[davelester]

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:

1. Highlighting the New contributors call on December 20th https://forums.swift.org/t/swift-on-android-new-contributors-call/83729 would be great, especially if the post gets some online attention from the Android community. This is currently under the "Ongoing work" section but easily overlooked -- pulling it up to the intro would make it much more visible.
2. Announce 6.3 SDK snapshots of the Swift SDK for Android. This is currently added in a section at the bottom of the post, but bringing it right to the top would be fantastic.

[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.

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.

This is currently under the "Ongoing work" section but easily overlooked -- pulling it up to the intro would make it much more visible.

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.

Announce 6.3 SDK snapshots of the Swift SDK for Android. This is currently added in a section at the bottom of the post, but bringing it right to the top would be fantastic.

I was going for a "one more thing" Apple keynote effect, 😉 but happy to mention it twice if you think that's better.

[finagolfin]

I added most of the changes asked for, and teased the new 6.3 SDK snapshots at the top.