Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: adds mobile programming languages #945

Closed
wants to merge 4 commits into from
Closed

docs: adds mobile programming languages #945

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
fc55313
chore: remove redundant whitespace from standard
huwd Oct 7, 2024
a480d6d
chore: use content focused apostrophe to avoid compilation issues
huwd Oct 7, 2024
62ad7d4
Add JavaScript / Node.js as a first class backend langauge at GDS
huwd Oct 7, 2024
05a27ae
docs: adds initial section for kotlin/swift in programming languages …
mcgarj Oct 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 28 additions & 13 deletions source/standards/programming-languages.html.md.erb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,6 @@ This should make it easier for developers to:
The Service Manual has information on
[using client-side JavaScript][manual_js]. For server-side JavaScript we use [Node.js][nodejs].


[nodejs]: https://nodejs.org/
[manual_js]: https://www.gov.uk/service-manual/technology/using-progressive-enhancement

Expand All @@ -45,11 +44,11 @@ You can use Node.js to render a web interface for your service. For example,
GOV.UK Pay has created thin, client-facing applications that do not store
data (although they may retrieve data from an API).

You can use [TypeScript](https://www.typescriptlang.org/) when teams think it's
You can use [TypeScript](https://www.typescriptlang.org/) when teams think it’s
appropriate. For example, the GOV.UK PaaS team uses TypeScript
because they are used to working with a statically typed, compiled language,
and they think the compilation and static-analysis tooling is better for
their workflow. There's more information about TypeScript on the
their workflow. Ther’s more information about TypeScript on the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
their workflow. Ther’s more information about TypeScript on the
their workflow. There’s more information about TypeScript on the

[Node.js page](/manuals/programming-languages/nodejs/).

## Backend development
Expand All @@ -59,18 +58,16 @@ Our core languages for backend development are:
- [Java](/manuals/programming-languages/java.html)
- [Python](/manuals/programming-languages/python/python.html)
- [Ruby](/manuals/programming-languages/ruby.html)
- [JavaScript / Node.js](/manuals/programming-languages/nodejs/index.html)

We've chosen these languages because they are successfully used by
We’ve chosen these languages because they are successfully used by
teams at the moment, and we are confident in how to host and operate
applications written in them. You should carry out new
development in one of these languages.

We are also currently exploring the use of Node.js in the backend for
serverless systems, particularly in the Digital Identity programme.

### Python

You should write new Python projects in Python 3.
You should write new Python projects in Python 3.
[Python 2 reached end of life in 2020][PEP373]. Python 3 is now well-supported
by application frameworks and libraries, and is commonly used in
production.
Expand Down Expand Up @@ -98,23 +95,41 @@ source tool available.
### Languages we do not use for new projects

We used Scala in the early days of GDS. GOV.UK Licensing is the only remaining
application written in Scala but we've found it hard to support because of a lack
application written in Scala but we’ve found it hard to support because of a lack
of skills in GDS. Do not use Scala for new projects.

## Mobile Development

For developing mobile apps, we use Swift for iOS and Kotlin for Android.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mcgarj in line with other docs, consider annotating some of the brand names here with links back to the product pages of that stuff.

So Swift, Kotlin, hell even iOS and Android.

Imagine you're reading this as a dev who (ahem... perhaps like me a few months ago) has zero starting point for this. Let's link richly through to the right pages so someone can go find out what we mean by Swift, Android or even iOS.


These languages have been chosen over using frameworks such as Flutter or .NET MAUI so that the apps
feel like a native Android/iOS app without writing extra code to account for the specific OS in Flutter, for example.
Comment on lines +105 to +106
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a great statement, and one I might like to see expanded.

I wonder if one of the mobile seniors or folks involved with these decisions wouldn't mind chipping in here?

I think there's a candidate here for a separate GDS Way page about "preferences for native first / web first or hybrid".

It'd be good if we could write this paragraph in a way we could link off to that when we have more guidance later.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'd be overreaching here to specify in this that we have an organisational preference for single platform mobile apps over cross platform tooling - as I understand DI and GOV.UK both made the decision to go single platform based on individual project requirements.

I think it'd be better to just leave how someone would approach a cross platform app as undefined here as we've not yet established a pattern/preferred framework in the org - and maybe we never will? And then to amend the above sentence to be: "For developing native mobile apps, we use Swift for iOS and Kotlin for Android."

I imagine there could be a sentence or two to explain why Kotlin over an alternative like Java for native Android development and why Swift over Objective-C for native iOS - but it could be a little superfluous given how dominant both languages in the sphere. So as an alternative something that just says "These languages have been chosen as they are the common industry standard and vendor recommended languages to use for their respective platforms"


### Swift

The Swift version is generally tied to the version of Xcode you're using. As long as the Xcode version supports the minimum targeted iOS version
of your team's app, you can use the most recent version if desired.
Comment on lines +110 to +111
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

huh the suggestion tool disappeared from github, I must be doing something odd...

Consider putting this on one line


// TODO: Do we need to mention minimum iOS targets for DI / GOV.UK?

### Kotlin

// TODO: Fill in specific Kotlin/Android Studio versions/ OS targets?

## Using other languages

There will be sensible reasons to not follow the above guidance on languages.
For example when you're:
For example when you’re:

- extending an existing codebase or ecosystem
- scripting in a particular environment
- experimenting during an alpha (with an expectation that it's replaced by something we have more confidence in for beta)
- experimenting during an alpha (with an expectation that it’s replaced by something we have more confidence in for beta)
- working in a very specific or unusual problem domain, like heavy use of WebSockets

The set of languages we're comfortable supporting will change over time.
The set of languages we’re comfortable supporting will change over time.

If you want to use a new language, talk to your Head of Technology and then create
a prototype. If it goes well you can [open a pull request](/standards/pull-requests.html) to change this document.

If you're having problems using one of the languages we support, open a pull request to
If you’re having problems using one of the languages we support, open a pull request to
document the issues.