DEV Community: sfrrvsdbbf

Swift Programming in Japanese

sfrrvsdbbf — Tue, 29 Apr 2025 06:02:21 +0000

This post is blog version of my talk on "try! Swift Tokyo 2025".

video link: https://www.youtube.com/watch?v=uVgxJpSvp-I

Intro

Programming has a history of over 50 years.
Historicaly, source code has been written in English.
Thanks to Unicode, modern programming languages support writing source code in natural languages other than English.
Swift is a modern programming language that was launched 10 years ago.
I tried Swift programming in Japanese.

Based on my experience in developing this app

App name: PlainShogi

Board game app.
It was released 3 years ago and has been updated continuously.
Developed it using a standard setup: Xcode, Swift, and SwiftUI.

By leveraging SwiftUI, I actively supported multiple platforms.

What's Shogi?

A traditional Japanese strategy board game.
Played on a 9x9 board with unique piece movement rules.
Known as “Japanese chess”.

There are eight types of pieces in Shogi.

enum Piece: String {
    case 歩,
         角,
         飛,
         香,
         桂,
         銀,
         金,
         王
}

This is the code of pieces.

Swift allows you to use Japanese for identifiers. That’s pretty nice.

I wrote the source code in Japanese so the pieces can be displayed as is on the UI. No additional code is required.

I actively considered these approaches for this app.

And I challenged myself to write almost all of the source code in Japanese.

In this post, I would like to write based on the experience.

What's “Swift programming in Japanese”?

Swift source files are encoded in UTF-8.
Swift is designed to allow non-English identifiers.
Reserved words and framework identifiers remain in English.
Using Japanese for naming identifiers.

In this post, we will call this “Swift programming in Japanese”.

Premise of this post

Mac
Xcode
Swift
Apple’s development tools and frameworks only
No special tools and configs
Based on my personal experience

Out of Scope for This Post

Advantages and disadvantages of non-English speakers using their native language for programming.
Whether non-English speakers should program in English.

Feasibility of Japanese identifiers

Consider whether the character can be used as an identifier.

Invalid characters

Xcode will display an error message for invalid characters. It will also fail to compile.

Let's examine characters by category.

Hiragana

Hiragana is the most basic character of the Japanese language.
Counting by Unicode standards, there are 80 characters.
All are valid.

Katakana

Katakana is similar in usage to italic fonts in English.
There are 81 characters.
All are valid.

Kanji

Kanji is Chinese characters adopted into Japanese writing system.
In Japan, about 3000 kanji characters are used.
All are valid.

Symbol

In Japan, these symbols are used. There are 32 symbols.

With regard to symbols, there are characters that can be used and characters that cannot be used.

Invalid Japanese symbols

13 invalid characters
Comma and Period
Brackets
Symbols written at the beginning or end of a sentence
These are generally unnecessary for identifiers

Combining characters

Unicode has a special type of characters.
These are combining characters.
Combining characters decorates one other character to create one new character.
In Japanese, there are combining characters for the voiced and semi-voiced marks.
These are valid.

Alphabet

Many Japanese do not speak English, but they use the alphabet.
It is used in combination with other character types.
Of course, the alphabet can be used as an identifier.

Arabic numerals

Arabic numerals are used in the same way.
Of course, they can be used as identifiers.

All Japanese characters

These are all commonly used Japanese characters. However, there are many more characters in Unicode.
If the number of characters that are actually used infrequently is included, the number is about twice as large.

In total, there are over 6500 characters. Almost all Japanese characters are valid. Invalid characters are only some symbols.

Does Swift compiler build properly?

Here are some concerns that come to mind.

Are there any bugs?
Does it behave differently from English?
Is there any performance loss?

No problem at all.

Does Xcode work properly?

Here are some concerns that come to mind.

Does it work as a text editor for Japanese in the first place?
Will suggestions and other features work smoothly?
Will Japanese fonts display properly?
It is common to use identifiers as file names. Is it okay to use Japanese file names?
Is Git built in to Xcode also okay?

All of these are fine. Everything works properly.

Test on Xcode

XCTest requires identifiers to begin with “test”. This is a little disappointing.

This has recently been resolved. In Swift Testing introduced in Xcode 16, there’s no need to prefix with “test”. That's great.

Answer of "Feasibility of Japanese identifiers"

So far, we have examined the feasibility of Japanese identifiers.

In short, Swift and Xcode fully support programming with Japanese identifiers!

Q: So, does everything work perfectly in Japanese?

The answer is NO.

Everything we have discussed so far has been about the inner workings of Swift.

Using Japanese outside of Swift can be risky

For example,

Xcode project name
Bundle Identifier
Name of File, Folder, or Target (* Only when using third-party development tools)
URL
Codable (* Only when decoding the data with other tools)

I told you earlier that file names are not a problem. However, please be careful when using third-party development tools. It is up to that development tool whether or not it supports Japanese.

Tips for code completion

In English, code completion is suggested with a single keyboard type. In Japanese, however, multiple keyboard types are required.

Tip 1: Keyboard shortcut

Display code completion using keyboard shortcut.

control + space
control + dot
option + escape

Tip 2: Using “self” or “Self”.

Using “self” or “Self” helps code completion work smoothly.

A medium-size issue: Naming convention

Case conventions are common. Names of types and protocols are UpperCamelCase. Everything else is lowerCamelCase.

However, there isn’t a well-established way to express these conventions in Japanese.

I tried various ways and searched online, but couldn’t find a solution.

* This issue applies to other programming languages as well

As an aside

Apple translates much of official information for developers into Japanese. They are very helpful to Japanese speakers with their high-quality translations.

Top page
Feature page
News
Video (title, description, subtitles)
Human Interface Guidelines

All of these have official Japanese translations. These provide strong support for Japanese speakers, especially in keeping up with OS updates + new devices.

By the way, Japanese translations do not exist for the API reference, tutorial series, and Xcode UI. Conversely, there are Japanese translations for all but these three.

As an aside(2)

The Swift Programming Language(日本語版)
https://www.swiftlangjp.com

There is a volunteer project to translate the official Swift reference into Japanese.

Request

Request to Swift and Xcode

As I have explained, Swift and Xcode fully support Japanese identifiers. Therefore, no request was necessary.

There is no requirement for reserved words, frameworks, or Xcode UI to be in Japanese.

Request to Japanese speakers

Let’s write Japanese identifiers!

No preparation is required because it's pure Swift.
You can write alongside English, allowing gradual introduction.
Let’s find the best practices together. Especially naming convention.

Request to Non-English speakers

Let’s write YOUR native language identifiers!

Wrap-up

Swift works properly with Japanese identifiers.
It’s unsafe to use Japanese outside Swift.
Let’s try Swift programming in Japanese.

【visionOS/ARKit】Simplest sample code for hand tracking【latestAnchors ver】

sfrrvsdbbf — Mon, 22 Jul 2024 12:43:30 +0000

The basis of ARKit's hand tracking API in visionOS is to obtain data such as coordinates and rotation of each joint of the hand.

Here is a sample code of ARKit's hand tracking API in visionOS that works with only 73 lines of code.

Basic Knowledge

First, watch this session video. It gives a good overview of ARKit and hand tracking in visionOS.

Meet ARKit for spatial computing - WWDC23 - Videos - Apple Developer

Hand tracking is explained from 15:05.

Two APIs

There are two APIs to get joint data. Both can be accessed from the HandTrackingProvider instance.

anchorUpdates: receives the latest values via AsyncSequence.
latestAnchors: contains the latest values.

In this case, I implemented it with anchorUpdates.

link: AsyncSequence ver

Overview of the Sample Code

Starts hand tracking when the app launches.
Places simple sphere objects at all joints of both hands.
Updates each object’s position to match the latest joint position.
Ensures the objects are not hidden by the hand.

Full Source Code



import SwiftUI
import RealityKit
import ARKit

@main
struct MyApp: App {
    var body: some SwiftUI.Scene {
        ImmersiveSpace {
            RealityView { content in
                for chirality in [HandAnchor.Chirality.left, .right] {
                    for jointName in HandSkeleton.JointName.allCases {
                        let jointEntity = ModelEntity(mesh: .generateSphere(radius: 0.006),
                                                      materials: [SimpleMaterial()])

                        jointEntity.components.set(JointComponent(chirality: chirality,
                                                                  jointName: jointName))

                        content.add(jointEntity)
                    }
                }
            }
        }
        .upperLimbVisibility(.hidden)
    }

    init() {
        JointComponent.registerComponent()
        JointSystem.registerSystem()
    }
}

struct JointComponent: Component {
    let chirality: HandAnchor.Chirality
    let jointName: HandSkeleton.JointName
}

struct JointSystem: System {
    private let session = ARKitSession()
    private let provider = HandTrackingProvider()

    init(scene: RealityKit.Scene) {
        setUpSession()
    }

    private func setUpSession() {
        Task {
            try! await session.run([provider])
        }
    }

    func update(context: SceneUpdateContext) {
        let entities = context.entities(matching: .init(where: .has(JointComponent.self)),
                                        updatingSystemWhen: .rendering)

        let (leftHandAnchor, rightHandAnchor) = provider.latestAnchors

        for handAnchor in [leftHandAnchor, rightHandAnchor] {
            guard let handAnchor else { continue }

            for entity in entities {
                let component = entity.components[JointComponent.self]!

                guard component.chirality == handAnchor.chirality,
                      let joint = handAnchor.handSkeleton?.joint(component.jointName) else {
                    continue
                }

                entity.setTransformMatrix(handAnchor.originFromAnchorTransform * joint.anchorFromJointTransform,
                                          relativeTo: nil)
            }
        }
    }
}

Copy and paste this code to use it.

Additional Steps

Set any text for “NSHandsTrackingUsageDescription” in Info.plist.
Set “Preferred Default Scene Session Role” to “Immersive Space” in Info.plist.

Comments

The explanations in the session video and the basic knowledge of SwiftUI and RealityKit are omitted.

latestAnchors?

https://developer.apple.com/documentation/arkit/handtrackingprovider/4189752-latestanchors

The most recent hand anchors for each hand.
Accessing this tuple consumes its values and sets them to nil until the next anchor update.

ECS



struct JointComponent: Component {
    let chirality: HandAnchor.Chirality
    let jointName: HandSkeleton.JointName
}

struct JointSystem: System {
    ...

    func update(context: SceneUpdateContext) {
        let entities = context.entities(matching: .init(where: .has(JointComponent.self)),
                                        updatingSystemWhen: .rendering)

        let (leftHandAnchor, rightHandAnchor) = provider.latestAnchors

        ...
    }
}

I implemented polling using the ECS (Entity Component System) pattern, a common implementation in RealityKit.

Setting Access Permissions

To request access permissions, you need to set any text for “NSHandsTrackingUsageDescription” in Info.plist.

This key does not appear in the pull-down menu, so enter it directly.

Hands occlusion

Sets the preferred visibility of the user’s upper limbs, while an ImmersiveSpace scene is presented.
The system can show the user’s upper limbs during fully immersive experiences, but you can also hide them, for example, in order to display virtual hands instead.
https://developer.apple.com/documentation/swiftui/scene/upperlimbvisibility(_:)



.upperLimbVisibility(.hidden)

Launch the App in Full Space



@main
struct MyApp: App {
    ...
    var body: some SwiftUI.Scene {
        ImmersiveSpace {
            ...
        }
        ...
    }
}

When you create a new visionOS app project in Xcode, it generates code to launch in a window. For simplicity, I made it launch in full space.

Set “Preferred Default Scene Session Role” to “Immersive Space” in Info.plist. If you do not make this setting, the app will crash right after launch.

Note: A Physical Device is Required

You need a physical device to test the ARKit Hand Tracking API. It does not work at all in the simulator.

Next Step

Check the current authorization status: session.queryAuthorization(for:)
Explicitly request authorization: session.requestAuthorization(for:)
Check the state of anchors: AnchorUpdate.Event
Check if each anchor or joint is being tracked: TrackableAnchor.isTracked
Observe the session state: ARKitSession.Events
Check if the current runtime environment supports it: HandTrackingProvider.isSupported

Links

Meet ARKit for spatial computing - WWDC23 - Videos - Apple Developer

ARKit in visionOS | Apple Developer Documentation

upperLimbVisibility(_:) | Apple Developer Documentation

HandsRuler on the App Store

FlipByBlink/HandsRuler: Measure app by hand tracking for Apple Vision Pro

【visionOS/ARKit】Simplest sample code for hand tracking【AsyncSequence ver】

sfrrvsdbbf — Fri, 24 May 2024 02:50:57 +0000

The basis of ARKit's hand tracking API in visionOS is to obtain data such as coordinates and rotation of each joint of the hand.

Here is a sample code of ARKit's hand tracking API in visionOS that works with only 41 lines of code.

Basic Knowledge

First, watch this session video. It gives a good overview of ARKit and hand tracking in visionOS.

Meet ARKit for spatial computing - WWDC23 - Videos - Apple Developer

Hand tracking is explained from 15:05.

Two APIs

There are two APIs to get joint data. Both can be accessed from the HandTrackingProvider instance.

anchorUpdates: receives the latest values via AsyncSequence.
latestAnchors: contains the latest values.

In this case, I implemented it with anchorUpdates.

link: latestAnchors ver

Overview of the Sample Code

Starts hand tracking when the app launches.
Places simple sphere objects at all joints of both hands.
Updates each object’s position to match the latest joint position.
Ensures the objects are not hidden by the hand.

Full Source Code



import SwiftUI
import RealityKit
import ARKit

@main
struct MyApp: App {
    private let session = ARKitSession()
    private let provider = HandTrackingProvider()
    private let rootEntity = Entity()

    var body: some SwiftUI.Scene {
        ImmersiveSpace {
            RealityView { content in
                content.add(rootEntity)
                for chirality in [HandAnchor.Chirality.left, .right] {
                    for jointName in HandSkeleton.JointName.allCases {
                        let jointEntity = ModelEntity(mesh: .generateSphere(radius: 0.006),
                                                      materials: [SimpleMaterial()])
                        jointEntity.name = "\(jointName)\(chirality)"
                        rootEntity.addChild(jointEntity)
                    }
                }
            }
            .task { try! await session.run([provider]) }
            .task {
                for await update in provider.anchorUpdates {
                    let handAnchor = update.anchor
                    for jointName in HandSkeleton.JointName.allCases {
                        guard let joint = handAnchor.handSkeleton?.joint(jointName),
                              let jointEntity = rootEntity.findEntity(named: "\(jointName)\(handAnchor.chirality)") else {
                            continue
                        }
                        jointEntity.setTransformMatrix(handAnchor.originFromAnchorTransform * joint.anchorFromJointTransform,
                                                       relativeTo: nil)
                    }
                }
            }
        }
        .upperLimbVisibility(.hidden)
    }
}

Copy and paste this code to use it.

Additional Steps

Set any text for “NSHandsTrackingUsageDescription” in Info.plist.
Set “Preferred Default Scene Session Role” to “Immersive Space” in Info.plist.

Comments

The explanations in the session video and the basic knowledge of SwiftUI and RealityKit are omitted.

Managing Each Entity



jointEntity.name = "\(jointName)\(chirality)"



let jointEntity = rootEntity.findEntity(named: "\(jointName)\(handAnchor.chirality)")

Each entity is managed by its name using HandSkeleton.JointName for joint names and HandAnchor.Chirality for left or right hand.

Hands occlusion

Sets the preferred visibility of the user’s upper limbs, while an ImmersiveSpace scene is presented.
The system can show the user’s upper limbs during fully immersive experiences, but you can also hide them, for example, in order to display virtual hands instead.
https://developer.apple.com/documentation/swiftui/scene/upperlimbvisibility(_:)



.upperLimbVisibility(.hidden)

Setting Access Permissions

To request access permissions, you need to set any text for “NSHandsTrackingUsageDescription” in Info.plist.

This key does not appear in the pull-down menu, so enter it directly.

Launch the App in Full Space



@main
struct MyApp: App {
    ...
    var body: some SwiftUI.Scene {
        ImmersiveSpace {
            ...
        }
        ...
    }
}

When you create a new visionOS app project in Xcode, it generates code to launch in a window. For simplicity, I made it launch in full space.

Set “Preferred Default Scene Session Role” to “Immersive Space” in Info.plist. If you do not make this setting, the app will crash right after launch.

Note: A Physical Device is Required

You need a physical device to test the ARKit Hand Tracking API. It does not work at all in the simulator.

Next Step

Check the current authorization status: session.queryAuthorization(for:)
Explicitly request authorization: session.requestAuthorization(for:)
Check the state of anchors: AnchorUpdate.Event
Check if each anchor or joint is being tracked: TrackableAnchor.isTracked
Observe the session state: ARKitSession.Events
Check if the current runtime environment supports it: HandTrackingProvider.isSupported

Links

Meet ARKit for spatial computing - WWDC23 - Videos - Apple Developer

ARKit in visionOS | Apple Developer Documentation

upperLimbVisibility(_:) | Apple Developer Documentation

HandsRuler on the App Store

FlipByBlink/HandsRuler: Measure app by hand tracking for Apple Vision Pro

2 Tips to improve "unfriendly" iPad apps 【SwiftUI】

sfrrvsdbbf — Mon, 29 Apr 2024 04:42:09 +0000

iPhone apps can run as iPad apps simply by adding iPad as a build target. However, without some optimization for the iPad, the app can be very user-unfriendly. Unfortunately, such iPad apps are not uncommon in the App Store.

In this article, I will introduce two minimal techniques to make "unfriendly" iPad apps decent with just a few adjustments.

Target

Primarily an iPhone app
Limited resources for iPad compatibility
Uses common UI patterns (bottom tabs, stack navigation, lists, etc.)

struct ContentView: View {
    var body: some View {
        TabView {
            NavigationStack {
                List {
                     /* … */
                }
                .navigationTitle("Home")
                .toolbar {
                    EditButton()
                    ShareLink(item: .init())
                }
            }
            .tabItem { Label("Home", systemImage: "house") }
            /* … */
        }
    }
}

Tip 1: Support Landscape Orientation

Many iPhone apps only support portrait orientation, and many iPad apps follow suit. iPad users generally use their devices in landscape orientation, and it can be frustrating to use apps that only support portrait mode. Unless there is a special reason, you should support landscape orientation.

Tip 2: Avoiding Unnecessary Horizontal Stretching of Content

A typical issue when adapting an iPhone app for the iPad in landscape orientation is that the content stretches too much horizontally, which looks unnatural. Ideally, you would redesign the app's UI specifically for the iPad, but that requires significant resources. Here, we introduce the approach of adding margins to the left and right sides of the content, which is commonly used in many apps.

struct AddSpace: ViewModifier {
    func body(content: Content) -> some View {
        GeometryReader {
            content
                .safeAreaPadding(.horizontal,
                                 $0.size.width > 1100 ? 200 : 0)
        }
    }
}
//===================================
struct ContentView: View {
    var body: some View {
        TabView {
            NavigationStack {
                List { 
                    /* … */
                }
                .modifier(AddSpace())
                /* … */
            }
            /* … */
        }
    }
}

For Lists and ScrollViews, just adding padding on the sides can disrupt the appearance and gesture recognition area. We adjusted the left and right safe areas to add margins, allowing us to maintain a usable design without changing the iPhone app's layout.

Challenge of Split View

A typical design for landscape-oriented iPad apps includes using a sidebar for a Split View. If you simply replace a bottom tab with a sidebar for a selection-based Split View, it seems feasible to achieve a good result without allocating additional resources.

struct ContentView: View {
    @State private var selection: String? = “Home”
    var body: some View {
        NavigationSplitView {
            List(selection: self.$selection) {
                Label("Home", systemImage: “house”).tag("Home")
                Label("Favorite", systemImage: “star”).tag("Favorite")
                Label("Setting", systemImage: "gearshape").tag("Setting")
                Label("Help", systemImage: "info").tag("Help")
            }
        } detail: {
            switch self.selection {
                case "Home": /* … */
                case "Favorite": /* … */
                case "Setting": /* … */
                case "Help": /* … */
                default: /* … */
            }
        }
    }
}

When you actually try this, it will require dedicating resources in various ways. For example:

Considering different scenarios, such as when the window width is narrow
Testing the behavior differences of content view instances when switching tabs (they don’t disappear with bottom tabs but disappear with Split View)
Testing the operation of the navigation stack in the detail panel (toolbars and navigation links often behave unexpectedly)
Starting unnecessary implementations like "adding sidebar items" or "automatic switching between bottom tabs and sidebar" due to getting carried away

If you have no experience with implementing Split View, I do not recommend diving into it casually.

Note 1: Disable Multiple Windows

Unlike iPhones, iPads can have multiple windows. To avoid issues from unexpected user inputs, disable multiple windows by setting "Enable Multiple Windows" to NO in Info.plist.

Note 2: Implementing iPad-Specific Code

You should use UIDevice.current.userInterfaceIdiom.

struct ContentView: View {
    var body: some View {
        switch UIDevice.current.userInterfaceIdiom {
            case .phone: Text(“I am iPhone")
            case .pad: Text(“I am iPad")
            default: EmptyView()
        }
    }
}

DEV Community: sfrrvsdbbf

Swift Programming in Japanese

Intro

Based on my experience in developing this app

What's Shogi?

What's “Swift programming in Japanese”?

Premise of this post

Out of Scope for This Post

Feasibility of Japanese identifiers

Invalid characters

Hiragana

Katakana

Kanji

Symbol

Invalid Japanese symbols

Combining characters

Alphabet

Arabic numerals

All Japanese characters

Does Swift compiler build properly?

Does Xcode work properly?

Test on Xcode

Answer of "Feasibility of Japanese identifiers"

Q: So, does everything work perfectly in Japanese?

Using Japanese outside of Swift can be risky

Tips for code completion

Tip 1: Keyboard shortcut

Tip 2: Using “self” or “Self”.

A medium-size issue: Naming convention

As an aside

As an aside(2)

Request

Request to Swift and Xcode

Request to Japanese speakers

Request to Non-English speakers

Wrap-up

Links

PlainShogi app

PlainShogi's source code

my GitHub

my X

This talk's video

Slide version

web site of "try! Swift Tokyo"

【visionOS/ARKit】Simplest sample code for hand tracking【latestAnchors ver】

Basic Knowledge

Two APIs

Overview of the Sample Code

Full Source Code

Additional Steps

Comments

latestAnchors?

ECS

Setting Access Permissions

Hands occlusion

Launch the App in Full Space

Note: A Physical Device is Required

Next Step

Links

【visionOS/ARKit】Simplest sample code for hand tracking【AsyncSequence ver】

Basic Knowledge

Two APIs

Overview of the Sample Code

Full Source Code

Additional Steps

Comments

Managing Each Entity

Hands occlusion

Setting Access Permissions

Launch the App in Full Space

Note: A Physical Device is Required

Next Step

Links

2 Tips to improve "unfriendly" iPad apps 【SwiftUI】

Target

Tip 1: Support Landscape Orientation

Tip 2: Avoiding Unnecessary Horizontal Stretching of Content

Challenge of Split View

Note 1: Disable Multiple Windows

Note 2: Implementing iPad-Specific Code