When I started making apps in 2011, it was thrilling to go from an idea to something you could physically touch and hold in your hand within hours. Today, that same feeling exists—but the iteration cycles are now an order of magnitude faster.

The fundamentals haven’t changed. What has changed is the speed at which intent turns into working software.

Translation Is (Basically) a Solved Problem

A lot of where AI applications go wrong today comes from anthropomorphizing models and ascribing to them a kind of human-style intelligence. As Andrej Karpathy puts it: “We’re summoning ghosts, not building animals.”

But one category of tasks these LLM “ghosts” excel at is translation.

That’s obvious when translating natural language like English to French, but it’s equally true for:

• TypeScript to Swift
• Jetpack Compose to SwiftUI
• Web APIs to platform SDKs
• Architectural patterns across platforms

See this example where Simon Willison ported JustHTML from Python to JavaScript with Codex CLI and GPT-5.2 in 4.5 hours.

If you operate in an environment where your web app, iOS app, and Android app are separate codebases with baseline functional parity, AI fundamentally changes the economics of one codebase for each platform.

Instead of rewriting features, you’re translating intent.

A web PR becomes a reference implementation. Existing mobile code becomes executable context. Asking an agent to “take a first pass at implementing this natively” is now a normal—and productive—workflow, especially for apps with large CRUD-style surface areas and well-defined business logic.

Context Beats Code

Simon Willison has written about context engineering: “the art of providing all the context for the task to be plausibly solvable by the LLM.” The limiting factor in AI-assisted development isn’t the model itself, but how clearly the problem is framed.

That aligns closely with what actually matters in software engineering:

• Understanding the domain
• Choosing the right abstractions
• Designing the architecture
• Encoding business rules correctly
• Setting up the right conditions for QA and validating core behavior and edge cases

These are platform-agnostic, one-time costs. Once you’ve paid them, the knowledge transfers cleanly across platforms.

This is also where the distinction between process-driven and outcome-driven engineers becomes important. As Ben Werdmuller put it, we’re likely to see a real split between people who are outcome-driven and excited to test their work with users faster, and people who are process-driven and derive meaning primarily from the engineering itself.

LLMs disproportionately benefit outcome-driven engineers—those who know what “good” looks like and can steer toward it. The tools reward clarity of intent, not ceremony.

What Mobile Development Actually Looks Like Now

In practice, most of the code I’ve written over the past twelve months hasn’t been typed directly into Xcode or Android Studio.

A common setup today looks like this:

• A coding agent (e.g. Claude Code, Cursor, etc.) on one side of the screen
• Xcode or Android Studio on the other
• The bulk of code editing happening in the agent
• The IDE acting as a platform-native harness: breakpoints, debugger, previews, and deeper integrations with simulators and emulators

With a modest amount of investment, the need for an IDE as a primary input tool almost disappears. The more you can hoist your compiler and language server out of the IDE and into terminal-ready commands, the more you can augment the capabilities of your coding agent.

Native Platforms Pair Well With AI, Despite Training Gaps

A fair concern is that frontier models still have less deep knowledge of iOS- and Android-specific APIs than they do of web or Python ecosystems.

Matt Gallagher recently wrote about the state of Swift and iOS knowledge in frontier models at the end of 2025. He notes that “most LLMs are trained on data that is 2+ years old, and their Swift style often feels older still.”

The conclusion isn’t that models are perfect, but that modern native platforms provide strong constraints:

• Strong static typing
• Clear compiler diagnostics
• Declarative UI frameworks
• Deterministic tooling

These constraints matter more than raw training data volume. What matters day to day isn’t whether an LLM can one-shot a perfect solution, but whether it can iterate quickly with tight feedback. Strong typing in Swift, Kotlin, and TypeScript helps enormously here.

I don’t know about you, but I don’t typically write perfect code on the first try either.

A Brief Note on React Native

It’s absolutely possible to build excellent mobile apps using React Native or fully native stacks.

What’s often underestimated is the organizational overhead and depth of expertise required to do React Native well at scale. Teams that succeed tend to invest heavily in platform infrastructure, tooling, and internal knowledge. Shopify is a well-known example of what “doing it right” looks like.

AI shifts this tradeoff. When translation becomes cheap, the value of lowest-common-denominator abstractions drops. Platform-idiomatic code no longer implies slower delivery.

Side note: this is a large part of why Ramp’s mobile engineering team is much leaner than people expect given the breadth of the apps’ capabilities.

The Centaur Model, Applied

This way of working maps closely to what Cory Doctorow calls the Centaur model. In automation theory, “a centaur” is a person assisted by a machine.

Humans and machines work together, each focused on what they do best:

• Humans handle judgment, architecture, domain understanding, and taste
• Machines handle repetition, translation, and acceleration

AI doesn’t remove the need for software engineers. It removes the least interesting parts of the job and sharpens the most important ones.

Why This Reinforces Native Teams

With AI-assisted translation:

• Separate codebases no longer incur the same maintenance costs as they once did
• Platform fidelity no longer trades off against velocity
• Engineers can build where they’re strongest and port confidently

This is exactly how we’re working today—and why Ramp is hiring iOS engineers and Android engineers.

If you care about building platform-idiomatic mobile apps, moving quickly without sacrificing quality, and spending more time on judgment than boilerplate, this is a particularly good moment to be doing native mobile engineering.

Closing

The tools changed.
The job didn’t.

If anything, it got more interesting.

Kind of like a modern day record player, but infinitely more extensible, and with each album costing 1/100th the price of a vinyl record.

Here it is in action (music starts 9 seconds into the video, set your volume to low):

And here’s how we built it:

Materials

• Amazon Echo Dot, $20: For the price, this is a surprisingly hackable, portable speaker. I would have prefered something without any microphones at all, but I mostly trust the hardware mute switch.
• Case, $20: Beautiful retro-style case for the Raspberry Pi. The top compartment is made to house a fan, but this is where I put the NFC module instead. The folks who make this at C4 Labs were super nice. We broke a piece when we started building the box and they sent a replacement part right away.
• Raspberry Pi, $35: I chose to go with a Raspberry Pi because they’re cheap, have good compatible NFC modules, lots of case options on Etsy and easy to develop on.
• NFC Module, $5: I can’t believe this thing is just $5. Works great. Lots of good tutorials on connecting this to a Raspberry Pi.
• NFC Cards, $29: I got 100 cards at $0.29 each.

In total, this adds up to $109, but in my case I already had a Raspberry Pi and an Echo Dot lying around that I could repurpose for this, so it cost me closer to $55.

Services

I’m already an Apple Music subscriber, so using that as the music source was the cheapest solution, although this setup would work with any music service that works with Amazon Echo: Spotify, Amazon Music, TuneIn, CloudPlayer, Deezer, iHeartRadio.

In the exploration phase for this project, I wanted to buy DRM-free music, wire a speaker directly to the Raspberry Pi and play it locally. However, that would have meant that adding music later would be a much more tedious task. Plus it’s hard to find DRM-free music these days, and when you do find what you want it ends up being pricey. Especially compared to the convenience and cost of today’s streaming options.

I also explored using HomePods as the speakers (see addendum below).

The biggest downside to the current streaming approach is that there’s a 5-10 second delay after tapping a card and music starting.

Assembly

I assembled this with my son over a few days in May 2020, and then finished the setup in September 2021. The actual hardware assembly probably only took a combined total of 3 hours though.

Software

Disclaimer: This code is rough, it’s suitable for a toy project. I’m sharing it in case it’s useful for others getting started with a similar, project. I’m not claiming this is beautiful quality code.

Echo Dot Remote Control

I use the alexa-remote-control shell script to control the Echo Dot. When it’s up and running, it couldn’t be easier:

1
2
3
4

$ alexa_remote_control.sh -e "playmusic:APPLE_MUSIC:The Lion King"
$ alexa_remote_control.sh -e pause
$ alexa_remote_control.sh -e play
$ alexa_remote_control.sh -e vol:15

NFC Reader

I use MFRC522-python to interface with the NFC module.

The Python script that reads cards and plays music looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

import RPi.GPIO as GPIO
import MFRC522
import os
import signal

continue_reading = True
last_seen_card = None
echo_name = "MusicBox Echo"
current_dir = os.path.dirname(os.path.abspath(__file__))
alexa_control_script = os.path.join(current_dir, "alexa_remote_control.sh")

def alexa(command):
    os.system(
        '{alexa_control_script} -d "{echo_name}" -e "{command}"'.format(
            alexa_control_script=alexa_control_script,
            echo_name=echo_name,
            command=command,
        )
    )

def pause():
    alexa("pause")

def play_music(query):
    print(query)
    pause()
    alexa("playmusic:APPLE_MUSIC:{query}".format(query=query))

def set_volume(volume):
    alexa("vol:{volume}".format(volume=volume))

def end_read(signal, frame):
    global continue_reading
    continue_reading = False
    GPIO.cleanup()

signal.signal(signal.SIGINT, end_read)

MIFAREReader = MFRC522.MFRC522()

while continue_reading:
    # Scan for cards
    (status, TagType) = MIFAREReader.MFRC522_Request(MIFAREReader.PICC_REQIDL)

    # If we have a card, continue
    if status == MIFAREReader.MI_OK:
        # Get the UID of the card
        (status, uid) = MIFAREReader.MFRC522_Anticoll()

        # If we have the UID, continue
        if status == MIFAREReader.MI_OK and last_seen_card != uid:
            last_seen_card = uid

            # Print UID
            print("Card UID: %s" % uid)
            if uid == [136, 4, 76, 240, 48]:
                print("PAUSE")
                pause()
            elif uid == [136, 4, 236, 236, 140]:
                set_volume(10)
            elif uid == [136, 4, 247, 42, 81]:
                set_volume(40)
            elif uid == [136, 4, 137, 170, 175]:
                play_music("Star Wars A New Hope Soundtrack")
            elif uid == [136, 4, 148, 191, 167]:
                play_music("Paco de Lucia")
            elif uid == [136, 4, 160, 224, 204]:
                play_music("Dexter Gordon")
            elif uid == [136, 4, 197, 238, 167]:
                play_music("Rainbow Connection")
            elif uid == [136, 4, 2, 220, 82]:
                play_music("Genesis")
            elif uid == [136, 4, 232, 57, 93]:
                # and so on...

You’ll notice that there are special cards for pausing, setting a high volume and setting a low volume. The rest of the cards map to music.

The main thing I’d like to improve at some point is to avoid hardcoding a mapping of the card UIDs to music and instead program it using the companion iPhone app by writing a payload to the card. The iOS side I know how to do pretty quickly, but I’d have to spend more time to figure out how to do it on the MFRC522 reader side of things.

API Server

There’s an API server that can be used to control the music box using the companion iPhone app.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

from flask import Flask, request, jsonify
import os

api = Flask(__name__)
echo_name = "MusicBox Echo"
current_dir = os.path.dirname(os.path.abspath(__file__))
alexa_control_script = os.path.join(current_dir, "alexa_remote_control.sh")

def alexa(command):
    os.system(
        '{alexa_control_script} -d "{echo_name}" -e "{command}"'.format(
            alexa_control_script=alexa_control_script,
            echo_name=echo_name,
            command=command,
        )
    )

@api.route("/pause", methods=["POST"])
def pause():
    alexa("pause")
    return "{}"

@api.route("/play", methods=["POST"])
def play():
    if request.json:
        play_music(request.json["query"])
    else:
        alexa("play")
    return "{}"

@api.route("/play/<query>", methods=["POST"])
def play_music(query):
    print(query)
    pause
    alexa("playmusic:APPLE_MUSIC:{query}".format(query=query))
    return "{}"

@api.route("/volume/<int:volume>", methods=["POST"])
def set_volume(volume):
    alexa("vol:{volume}".format(volume=volume))
    return "{}"

if __name__ == "__main__":
    api.run(host="0.0.0.0")

iPhone App

Of course I made an iPhone app using SwiftUI & Composable Architecture.

This helps me quickly adjust the volume, play/pause and play specific music. If my kid falls alseep to music, I can stop it without having to walk into his room.

Siri intents work too, so I can play/pause music by speaking to Siri without having to launch the app.

Closed Source

Hopefully this post is helpful to someone interested in building something similar. I’ve posted enough code and details to get you started, but I won’t be open sourcing the whole project because I’m just not willing to field support questions or feature requests. I’m happy to answer questions about my experience building this, but I’m sorry I can’t help you figure out why something’s not working if you go build something similar.

Addendum: HomePod Attempt

At one point I wanted to use a stereo pair of HomePods for this project, but all my attempts to reverse engineer a way to play music on them from a Raspberry Pi were fruitless. I tried sniffing the network traffic via Charles Proxy while playing music from the iOS Music app or even the Shortcuts app and wasn’t able to crack it. I did end up getting it working using forked-daap but this set the HomePods in a weird state. I don’t remember all the details because I gave up on that approach for two reasons: the first is that I couldn’t get it to work well and the second is that I wanted to keep the HomePods in our living room while the music box was meant to be in my son’s bedroom.

Update: Since writing this post, I learnt that SwiftSyntax’s upcoming byte tree deserialization mode will speed this up considerably. I hope to post a follow-up article on this shortly.

I have for some time been looking forward to reimplementing some of SwiftLint’s simpler syntax-only rules with SwiftSyntax. If you’re not familiar with it, the recent NSHipster article gives a great overview. My motivation for integrating it into SwiftLint was that it would be nice to use an officially maintained library directly to obtain the syntax tree rather than the open source but community-maintained SourceKitten library. I was also under the false impression that SwiftSyntax would be significantly faster than SourceKit/SourceKitten.

SourceKitten gets its syntax tree by dynamically loading SourceKit and making cross-process XPC calls to a SourceKit daemon. In a typical uncached lint run, SwiftLint spends a significant amount of time waiting on this syntax tree for each file being linted. Because SwiftSyntax is code-generated from the same syntax definition files as the Swift compiler, I had (incorrectly) assumed that calculating a Swift file’s syntax tree using SwiftSyntax was done entirely in-process by the library, which would have lead to significant performance gains by avoiding the cross-process XPC call made by SourceKitten for equivalent functionality.

In reality, SwiftSyntax delegates all parsing & lexing to the swiftc binary, launching the process, reading its output from stdout and deserializing the JSON response into its SourceFileSyntax Swift type. This is repeated for each file being parsed 😱.

Launching a new instance of the Swift compiler for each file parsed is orders of magnitude slower than SourceKitten’s XPC call to a long-lived SourceKit daemon.

I discovered this after reimplementing a very simple SwiftLint rule with a SwiftSyntax-based implementation: Fallthrough. This opt-in rule is a perfect proof-of-concept for integrating SwiftSyntax into SwiftLint because it literally just finds all occurrences of the fallthrough keyword and reports a violation at that location. I measured the time it took to lint a folder of ~100 Swift files from Lyft’s iOS codebase with only the fallthrough rule whitelisted.

1
2
3
4
5

# .swiftlint.yml configuration file
included:
  - path/to/lint/dir # contains ~100 Swift files
whitelist_rules:
  - fallthrough

I compiled both SwiftLint from master and again with this fallthrough-swift-syntax branch with swift build -c release and named the binaries swiftlint-master and swiftlint-swift-syntax. I then benchmarked both binaries using the excellent hyperfine utility.

1
2
3
4
5
6
7
8
9
10
11
12

$ hyperfine './swiftlint-master lint --quiet --no-cache' './swiftlint-swift-syntax lint --quiet --no-cache'
Benchmark #1: ./swiftlint-master lint --quiet --no-cache
  Time (mean ± σ):     231.3 ms ±   5.1 ms    [User: 130.5 ms, System: 29.2 ms]
  Range (min … max):   224.3 ms … 238.3 ms
 
Benchmark #2: ./swiftlint-swift-syntax lint --quiet --no-cache
  Time (mean ± σ):      5.254 s ±  0.149 s    [User: 20.309 s, System: 23.110 s]
  Range (min … max):    4.839 s …  5.354 s
 
Summary
  './swiftlint-master lint --quiet --no-cache' ran
   22.71 ± 0.82 times faster than './swiftlint-swift-syntax lint --quiet --no-cache'

The SwiftSyntax version was 22x slower than the existing SourceKitten version

Note that I ran SwiftLint with its caching mechanism and logging disabled to accurately measure the time it took just to perform the lint, rather than the overhead from logging or skipping the lint entirely by just returning cached results. Although logging only added 3ms to 10ms in my tests.

Ultimately, this means SwiftLint will be keeping its SourceKitten-based implementation for the foreseeable future, unless SwiftSyntax removes its reliance on costly compiler invocations and drastically improves its performance. I really hope the Swift team can somehow find a way to move parsing and lexing into SwiftSyntax itself, making the library much more appealing to use.

Norio Nomura and I (ok, honestly mostly Norio 😅) have been building a Swift library for encoding & decoding YAML for the last 18 months and it’s now stable enough to make a 1.0 release and share with the world.

It’s called Yams, you can find it on GitHub at jpsim/Yams and API docs are located at jpsim.com/Yams.

You could say it’s a Swift binding for LibYAML but I’d argue it’s much more than that.

I’m actually very happy with how this library ended up. It plays nicely with Swift 4’s Codable protocol, meaning that you get fast & type-safe encoding & decoding that feels right at home in modern Swift.

Here’s a simple example of encoding & decoding Codable types:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import Yams

struct S: Codable {
  var p: String
}

let s = S(p: "test")
let encoder = YAMLEncoder()
let encodedYAML = try encoder.encode(s)
encodedYAML == """
  p: test

  """
let decoder = YAMLDecoder()
let decoded = try decoder.decode(S.self, from: encodedYAML)
s.p == decoded.p

Alternatively, you can use it to work with Swift scalar & collection types, which is probably the easiest way to start parsing arbitrary YAML for your projects. Finally, there’s a third mode, which is a Yams-native API that best translates to how LibYAML works.

This library’s been powering a number of popular projects that use YAML for configuration, like SwiftLint, SwiftGen, XcodeGen & used in SourceKitten to parse Swift Package Manager build manifests. So if you’ve wanted to add YAML configuration files to your Swift CLI, or want to interoperate with other tools that process YAML, I encourage you to give Yams a try.

Goals

Host a self-contained, declarative infrastructure, password-protected, data-driven static photo gallery to share personal pictures with friends and family, without needing to run, maintain (or pay for) servers.

With the recent addition to our family, I wanted to set up a place where I could share pictures with our closest friends and family. Facebook wasn’t an option because… yeah, because many reasons actually.

Most of my family members are on Apple devices, while most of my friends are in the Google/Android ecosystem. So for day to day sharing of moments, we post a few pictures to iCloud photo sharing, and a few others to a WhatsApp group. But neither of these can really serve as the canonical place where we’re storing these photos long-term, because WhatsApp is pretty ephemeral, and the iCloud photo sharing experience sucks on non-Apple devices.

Architecture

Unfortunately there’s no “put a password in front of AWS CloudFront” checkbox. I wish there were, so I wouldn’t have had to build this. But there isn’t, so it was time to roll up my sleeves and learn a bit about how modern web infrastructure is built. Or at least my idea of it.

There are 7 main components:

1. CloudFront with restricted bucket access to prevent unauthenticated access to the site or its pictures.
2. Login lambda function to validate authentication and sign cookies to allow access to restricted buckets.
3. Source S3 bucket to store original pictures and metadata driving the site.
4. Resized S3 bucket to store resized versions of the original pictures.
5. Web S3 bucket to store the static website generated from the data in the source bucket.
6. Resize lambda function to automatically resize images added to the source S3 bucket and store them in the resized S3 bucket.
7. Site builder lambda function to automatically rebuild the static website when changes are made to the source S3 bucket.

Can it be simplified?

Of course. There are a few ways I can think of to simplify this, but the tradeoffs aren’t worthwhile IMO.

1. Resize images on demand. Rather than resize all the images when they’re first added to the source bucket, the resize lambda could be exposed via a CloudFront origin. However, since the static site only really uses two image sizes, and that lambda functions have a significant cold start penalty, it’s much more efficient to just precompute the resized images.
2. Consolidate buckets. Rather than separate source, resized & web buckets, they could just be in a single bucket. However, this would just shift the complexity a bit since the stack would then need to filter new object notifications to know which function to invoke. Plus, right now to back up the valuable content, I just need to periodically mirror the source bucket, rather than all the derivative data in the resized and web buckets.

Problems?

I have a few annoyances with this setup as-is.

One is that only the resized bucket triggers the site builder function. That means that any other object modified in the source bucket, such as the metadata.yml files that include album comments, don’t trigger a site build.

Another related problem is that for every new image in the source bucket, two are created in the resized bucket, each one invoking the site builder function. Not only that, but if I upload an album with lots of pictures all in one shot, the site will be rebuilt twice for each picture! 🙀

Unfortunately, S3 buckets can only have a single notification per event type, so we can’t trigger both the resize and site builder functions when new objects are created on the source bucket.

I think the solution here would involve publishing S3 events to SNS or SQS and “debouncing” the site builder lambda, but again… #complexity.

I’ll probably do this eventually, but I’m in no hurry.

Code

I’ve open sourced the entire AWS stack on GitHub over at jpsim/AWSPics. I’m also hosting a demo site over at awspics.net (use “username”/”password” as credentials to check it out).

There’s a (long) video walkthrough on YouTube too, if that’s useful to follow along.

Closing Thoughts

Overall, I really enjoyed stepping outside my comfort zone of native Swift/ObjC/C++ programming, learning a TON about several AWS services and ultimately meeting my goal of setting up a private photo gallery.

If you think incremental Xcode builds take a while, try deploying changes to an AWS CloudFormation stack 😅 pic.twitter.com/yTPsqarT92

— JP Simard (@simjp) July 2, 2017

What is SourceKit?

SourceKit is the set of tools that enables most of Swift’s source code manipulation features: source code parsing, syntax highlighting, typesetting, autocomplete, cross-language header generation, and lots more.

Architecture

Xcode traditionally runs its compiler (Clang) in-process, which means that any time the compiler would crash, so would the IDE.

Exacerbating the problem, Xcode can easily invoke the compiler thousands of times to parse, highlight and typeset source code, all before a user ever hits ⌘+B. That’s because unlike most editors (Vim/Sublime/etc), Xcode doesn’t use regular expressions to parse source code, but rather Clang’s powerful (though much more complex) parser/tokenizer.

Thankfully, Swift in Xcode 6 moves away from this architecture¹, combining all these source code manipulation features into a separate process that communicates with Xcode through XPC: sourcekitd. This XPC daemon is launched whenever Xcode 6 loads any Swift code.

How Xcode uses SourceKit

Since SourceKit is a private and undocumented tool, we need to get a little creative to learn how to use it. By setting the SOURCEKIT_LOGGING² environment variable, Xcode will log its SourceKit communications to stdout, allowing us to monitor its communications in realtime. This is how many of the commands covered in this article were discovered.

Unified Symbol Resolution

SourceKit uses a Clang feature called the USR (Unified Symbol Resolution) as a unique identifier for a source code token (i.e. class, property, method, etc.). This is what allows you to ⌘+click any token in Xcode and navigate to its definition. The USR is even more powerful now that it can unify a representation across languages (Swift/ObjC).

To print the USR’s from a Swift file (and their locations), you can run the following command:

1
2
3
4
5
6
7
8
9
10
11

$ xcrun swift-ide-test -print-usrs -source-filename=Musician.swift
10:7 s:C14swift_ide_test8Musician
14:9 s:vC14swift_ide_test8Musician4nameSS
19:9 s:vC14swift_ide_test8Musician9birthyearSu
33:5 s:FC14swift_ide_test8MusiciancFMS0_FT4nameSS9birthyearSu_S0_
33:10 s:vFC14swift_ide_test8MusiciancFMS0_FT4nameSS9birthyearSu_S0_L_4nameSS
33:24 s:vFC14swift_ide_test8MusiciancFMS0_FT4nameSS9birthyearSu_S0_L_9birthyearSu
34:9 s:vFC14swift_ide_test8MusiciancFMS0_FT4nameSS9birthyearSu_S0_L_4selfS0_
34:21 s:vFC14swift_ide_test8MusiciancFMS0_FT4nameSS9birthyearSu_S0_L_4nameSS
35:9 s:vFC14swift_ide_test8MusiciancFMS0_FT4nameSS9birthyearSu_S0_L_4selfS0_
35:26 s:vFC14swift_ide_test8MusiciancFMS0_FT4nameSS9birthyearSu_S0_L_9birthyearSu

Swiftish header generation

⌘+clicking on a token defined in Objective-C from Swift will cause Xcode to trigger a Swift-like header to be generated. I say Swift-like because this generated file is not valid Swift³, but at least displays the Swift syntax equivalent to the Objective-C tokens.

Using SourceKit from the command line

There are 3 main command line tools that allow to interact with SourceKit: sourcekitd-test, swift-ide-test and swift.

I compiled a shell script with documentation that runs through many useful commands like syntax highlighting, interface generation, AST parsing, demangling, and more.

The script is available on GitHub as a gist.

3rd Party Tools Using SourceKit

Because SourceKit lives outside of Xcode, it’s possible to leverage it to build anything from a Swift IDE to a documentation generator.

jazzy^♪♫

jazzy is a command-line utility that generates documentation for your Swift and Objective-C projects. It uses SourceKit to derive Swift syntax from Objective-C defined tokens (i.e. class, property, method, etc.).

SwiftEdit

SwiftEdit is a proof-of-concept editor that supports syntax highlighting for Swift files.

SourceKit & You

We’re just scratching the surface of what’s possible to build with SourceKit. Tools could be made to measure cross-language code coverage, or provide an editor where Objective-C and Swift can be edited simultaneously. Hopefully this article inspires you to build something with SourceKit and improve our tools in the process.

1: Objective-C in Xcode 6 (Beta 2) doesn’t use SourceKit at all, keeping Xcode’s traditional clang-in-process architecture. I expect this to change before Xcode 6 GM.

2: For SourceKit logging, launch Xcode with _{export SOURCEKIT_LOGGING=3 && /Applications/Xcode6-Beta2.app/Contents/MacOS/Xcode}

3: Speculation: I expect private Swift modules to expose public interfaces using a similar syntax once the language has access control mechanisms.

• Video
• Slides
• Slides Source

The first half of the talk covers the basic features and syntax of the language. The rest of the talk touches on some more in-depth discoveries about the runtime, introspection and how the tools work behind the scenes.

This article is more public service announcement than tutorial, since it’s really so easy you have no reason not to do it.

I’ll be showing you how to set up OpenVPN on DigitalOcean using tugboat, but any server provider will do.

1: Spin up an instance

$ tugboat create vpn

2: Install OpenVPN Access Server

1
2
3
4

$ tugboat ssh vpn
$ wget http://swupdate.openvpn.org/as/openvpn-as-2.0.6-Ubuntu13.amd64.deb
$ dpkg -i openvpn-as-2.0.6-Ubuntu13.amd64.deb
$ sudo passwd openvpn

The steps are 1) ssh, 2) download 3) install 4) set password. It’s that easy.

You can find the latest OpenVPN AS package for your system here.

3: Download your client

In the STDOUT from the dpkg -i, you’ll see a Client UI URL to connect to from your computer/smartphone to download the client. It’ll look like this:

1
2
3

$ Access Server web UIs are available here:
$ Admin  UI: https://123.456.789.123:943/admin
$ Client UI: https://123.456.789.123:943/

Accessing this URL will likely give you a certificate warning in your browser. This is because OpenVPN created a self-signed SSL certificate that your browser won’t recognize. You can either proceed anyway, or download the auto-generated cert from your machine directly, and then proceed. I wasn’t able to do this, so if you know how, please comment and I’ll update this article.

4: Connect

Install the client, connect and voilà. You’re now tunneling all your traffic through your vpn!

5 (optional): Save the DigitalOcean image

To save on cost, I only create this VPN server (from a saved image) when I need it and destroy it when I’m done. This saves on hosting costs AND DigitalOcean doesn’t actually charge for snapshots!!!

Final Thoughts

I’m writing this article from San Francisco’s public city WiFi, through my newly minted OpenVPN server, without fear of a malicious San Franciscan sniffing my sensitive data :).

The company has yet to launch, so I can’t say much about it, but I can tell you that I wouldn’t have joined it if I didn’t think it has the potential to change how software is built on a fundamental level.

This decision is actually the result of over 6 weeks of careful job hunting and deliberation, so it wasn’t done on a whim.

I’ve had a blast building Magnetic Bear Studios over the last 3 years, but it’s time to move on. The truth is, I’m a product builder, not a business builder. It’s what I love. And that’s what I’ll be doing at this new job. The other stuff was always incidental to me, but was taking up the majority of my attention.

I look forward to sharing more with you once we launch!

Check it out on GitHub or just add it to CocoaPods: pod 'JPSThumbnailAnnotation'.

I decided not to maintain the iOS 6 style, but iOS 6 is still supported.

By the way, this is what the old style looked like. It’s still in git, if you need to find it for some reason.

It’s a bit of a drag to have to set up NSNotification observers just to be able to keep your textfield on the screen when the keyboard barges into view. So I added a keyboardLayoutGuide to UIViewController myself. You can check it out on GitHub here: jpsim/JPSKeyboardLayoutGuide.

If you’ve used Apple’s layout guides before, you’ll know that they’re actually just id’s that conform to the UILayoutSupport Protocol. So I figured that having the guide just be a zero-sized UIView was probably the best way to go. This way, I can easily add it to the view and bind it to the keyboard frame by modifying a constraint’s constant.

In all honesty, I dislike the inheritance approach I took here; it seems like the easy way out. I’m hoping that either myself or a contributor will have a stroke of genius and find a composition-based way to do this. Perhaps a starting point would be a category on UIViewController along with an associated object as the keyboardLayoutGuide property… But then the NSNotifications will be troublesome. If you have an idea, please fork and send a PR or open up an issue on github!

One way to encourage a modular architecture is to use a dependency manager like Cocoapods. I’ve blogged about using Cocoapods before, but I didn’t touch on splitting up portions of your code that wouldn’t benefit from being open-sourced. Either because they’re too application-specific, or they’re proprietary.

For example, say you were building an application backed by a private web API, that needed to persist data to disk. A naïve implementation (read what most of us would do, including myself) would combine UI, API and persistence all in one project/workspace. In a fully modular app, UI/API/persistence would all have some degree of separation.

Private pods go a long way to help split up your codebase into logical modules. This becomes especially valuable in medium-large projects with 10k+ lines of code.

There are two main ways to make a private pod: remote and local.

Remote

You can either create a Specs-like private repo as indicated in this official Cocoapods guide or you can host your .podspec online and reference it directly in your Podfile.

Here’s how you’d reference it directly in a Podfile:

1

pod 'PrivatePod', :podspec => 'https://github.com/jpsim/JPSDisplayLink/raw/master/JPSDisplayLink.podspec'

Local

Though I find it unlikely, it might make sense to keep your private pods in the same repo as your project. In which case, you’d commit all its code in a special folder (i.e. local_pods/POD_NAME) and you’d specify the podspec path in your Podfile.

1

pod 'PrivatePod', :path => 'local_pods/PrivatePod'

In this case, the .podspec would be located at local_pods/PrivatePod/PrivatePod.podspec.

Note: I’ve had inconsistent results writing local podspecs. Specs that worked perfectly in a remote repo didn’t work at all locally for no apparent reason. Your mileage may vary, I might have made a stupid mistake.

Word of caution

Splitting up your codebase is not something you should do for its own sake. The additional overhead probably won’t be worthwhile in smaller projects. But the larger the project, the bigger the gain.

On that note, I hope this article helps you decide how you want to split your monolithic 300k line app. But hey, you could always build static libraries instead (cue laughter).

Source Control

Should you check in Podfile.lock? How about your *.xcworkspace and the Pods directory? Since all of these are automatically generated by running pod install, is it redundant to also include them in your source control?

Some CocoaPods maintainers recommend to check everything in.

My approach is to check in Podfile.lock but not xcworkspace and Pods. Here’s why:

Podfile.lock

Checking in Podfile.lock has the advantage of keeping track of the pod versions last used when working on the project. Also, if you run pod install and some pods have changed versions, you’ll see the change in your next commit, encouraging you to confirm that nothing broke.

Workspace

In most cases, checking in the *.xcworkspace to source control is unnecessary, since pod install will automatically generate it for you. There are rare cases in which you need to customize it, in which case you should check it in.

Pods Directory

Checking in the Pods directory is a contested issue. Checking it in allows full control of the pods and will ensure you review every change to your vendored code. Not checking it in will keep your code more decoupled from its dependencies and clean up your commit logs. I don’t do it because it ends up creating too many commit messages, especially if you’re using a library which is updated very often, like AFNetworking. Most dependency managers in other languages tend to not check in dependencies as well (i.e. npm & rubygems).

Finalizing a Project

If I’m going to stop working on a project for a while, or I’m handing it off to a client, I’ll create a branch with everything checked in. Podfile.lock, *.xcworkspace and Pods. This way, even if pods change over time, or they’re removed from github, or whatever happens, I’m sure to have a working version of my project.

Resources

No matter what strategy you choose to take for CocoaPods SCM, be aware of the pros/cons of each.

Here are a few resources to help you decide:

• Official CocoaPods .gitignore
• CocoaPods plugin to maintain pod integrity
• An interesting Twitter conversation about this article :)

Modifying Pods

Before modifying a pod, ask yourself if it’s necessary. Often, a category or subclass will do.

Pre-CocoaPods, when all vendored code was checked in, it was trivial to make small changes to 3rd party code. It’s still easy now, but not as obvious. There are many ways to make changes to Pods in your project:

1. Pull Request

If your modifications are useful to other users of the 3rd party library, then consider submitting a Pull Request. This way, everyone benefits. Hopefully it will be merged quickly.

2. Fork

Certain projects are notorious for taking a long time to merge PR’s (cough). In those cases or cases when your PR’s aren’t accepted, it can be useful to just point your Podfile to your fork of the project. Add this to your Podfile:

1

pod 'KIF', :git => 'https://github.com/ksuther/KIF'

The downside to this approach is that you have to keep your fork up to date, which is where the patchfile approach comes in.

3. Diffs

If your modifications are small, I’d encourage you to use patchfiles (*.diff) to apply them to your pods. This will apply your modifications every time you run pod install, with the added benefit of using the latest upstream updates. To see how it works, take a look at this github project: jpsim/pod-diffs.

Sidenote: patchfiles are super neat! Even if you modify code around your modification or the line numbers change, it’s smart enought to find it again!

4. Check it in

This is a last resort. If all other methods fail, check in your vendored code into your project outside of CocoaPods. Then, you’re free to modify it in any way you see fit. But then you need to update it manually when the upstream version changes.

Continuous Integration & Xcode Bots

There’s this misconception that using Xcode 5’s Bots feature for CI with CocoaPods projects means that you must check in your pods. In fact, Xcode Bots have the ability to run scripts prior to building your app. Check out this gist for a comprehensive guide to Bots and CocoaPods.

Thanks to @alloy, @aschndr, @ashfurrow & @swizzlr for their feedback while writing this article

This wasn’t too hard, but the I thought the process merited a short blog post.

I recently made a pixel-for-pixel clone of Apple’s iOS 7 UIImagePickerController (the camera portion, not the library portion). The full code can be found on github.

My motivation for doing this was that I was working on a client app that included functionality to take a picture and analyze it to determine whether or not it passed certain quality checks (legibility, resolution, completeness, etc). I wanted to display a message based on the result of this quality check during the “review” process of UIImagePickerController.

The part I want to discuss is the code that uses the phone’s hardware volume up button to snap a picture.

There are a few hurdles to jump over to make this seamless:

1. There’s no official API or notification to observe the audio volume or hardware volume button presses
2. UIImagePickerController doesn’t pass-through volume button presses to the system audio
3. There’s no official way to stop the system audio from being modified on a volume button press
4. The only way to disable the HUD that appears on volume change is to display an MPVolumeView (it won’t work if it’s hidden or if its alpha is zero)
5. The only way to set the system audio level is to use a deprecated method (i.e. if we want to undo a volume change caused by a volume button press)
6. The system audio volume won’t go up if it’s already set to 1 and won’t go down if it’s set to 0. This means that button presses won’t be registered if audio is at its maximum or its minimum.

So I wrote a class called JPSVolumeButtonHandler that solves the previous problems in the following way:

1. Create an off-screen MPVolumeView
2. If the volume is at 1, set it to 0.99999f, if it’s at 0, set it to 0.00001f, otherwise do nothing
3. KVO observe the outputVolume property of an AVAudioSession
4. Set the AVAudioSession’s category to AVAudioSessionCategoryAmbient to not duck any other volume
5. Trigger up/down code blocks when KVO notifies us of a change
6. Reset the system audio to its initial value when KVO notifies us that it has changed
7. Discard KVO notifications when the new volume value is the same as our initial value, since that means we reset the volume

Hopefully either the image picker clone, or this volume button class ends up being useful to a few people.

Thanks for reading!

The effort that went into getting a ticket is far more than I’m willing to admit… it’s JUST a conference, after all! Here’s a recap:

Early April

1. Start researching WWDC history to be well prepared (see last section). I felt this was critical to get a ticket.
2. Rumors and trends converge towards a June 10-14 schedule, with an April 25th announcement
3. Sign up to 2 different WWDC announcement notification services (for redundancy)
4. Book round-trip flights and accommodations early to avoid much higher costs once they skyrocket after the announcement.

April 25

1. 9:55, start repeatedly refreshing WWDC page
2. 10:00:05, see purchase button, enter info
3. 10:00:55, click “complete order”
4. Get error, enter info again
5. 10:01:55, click “complete order”
6. Get redirected to WWDC where it says “sold out”
7. Mope for a few minutes
8. Acceptance: Oh well, it’s just a conference. I’ll take this as a week-long vacation in SF. Go on with the rest of my day.
9. 16:30, receive a phone call from Apple rep saying “We see you encountered some errors while purchasing your WWDC tickets this morning. I’d like to let you know that we have a ticket reserved for you and we’ll be sending you an email with information on how to complete your purchase in the next twelve hours [sic].”
10. Celebrate for a few minutes

April 26

1. 14:27, receive email from Apple with instructions to complete the purchase
2. 16:00, attempt to complete the purchase but run into another set of errors on:
   • Google Chrome
   • OS X Safari
   • iOS Safari
   • Firefox
   • reset OS X Safari
   • it works!
3. Finally complete the order.

Note to self… avoid WWDC next year, people will be resort to writing bots to buy their tickets and the conference will sell out in 0.04s.

WWDC Stats

Conference Dates

• 2003: June 23 to June 27
• 2004: June 28 to July 2
• 2005: June 6 to June 10
• 2006: August 7 to August 11
• 2007: June 11 to June 15
• 2008: June 9 to June 13
• 2009: June 8 to June 12
• 2010: June 7 to June 11
• 2011: June 6 to June 10
• 2012: June 11 to June 15

Announcement Dates, Times and Sell Out Durations

• 2010: April 28 (8 days)
• 2011: March 28 (12hrs: 16x faster than previous year)
• 2012: April 25 (1h43m: 7x faster than previous year)
• 2013: April 25, 10:00am (90s: 70x faster than previous year)

This component was actually originally built at MBS for the ScalaOne iPhone app (now called TypesafeCon). You can find the original source here.

After seeing Sam Vermette’s talk on Saturday at NSNorth on Open Source and his philosophy towards it, I decided to go back and extract this little component. It was built pretty quickly at the time, so it was very tightly coupled to the app itself. So I abstracted it a bit, and chose to release it as an individual component. This should make it easier for other iOS developers to integrate this component into their own map apps.

Here’s to hoping we find a few things at Dashbook that we can release in the open in the near future!

From a logo on a napkin and a 200$ contract, to an exponentially growing mobile dev shop. One of my first big lessons running a young company was that it takes on a life of its own! It’s scary.

You’re focused 24/7 on finishing feature/contract #89 while dealing with time-sensitive business issues… and when you finally take a breath to look at where you are, you realize that the company itself has been evolving and pivoting. In a sense, it’s a bit like the saying goes:

Focus on what’s important and the rest will take care of itself.

What the saying fails to convey is that the rest may not be done the way you would do it.

Being a technical founder at a small company, I’ve had my head buried in code for the last few months. When I looked up again to assess where the business was going, I saw that the team’s interests were moving rapidly away from services towards building a product entirely ourselves.

To be fair, the goal from day one was always to evolve to a product company, so that seed was planted a long time ago.

But it was still difficult to let go of the services side. Of the CEO position and its responsibilities. Of the brand and company we had built from the ground up.

Ultimately, I couldn’t be more enthusiastic and confident about this new chapter. Being CTO of Dashbook, I’ll be focusing 100% on tech while relying on 2 extraordinary co-founders to take care of every other aspect of the business.

So the lesson here is that you have to let the company run its natural course. It has a mind of its own… and you should trust it!

I built it because I knew it would imply a bit of computer vision, OCR, basic set comparisons, yet it could probably be done in just a few hours.

Even though it will never make money and the codebase is slightly embarrassing, I feel reenergized after writing it and my mind is clearer.

Given that most of our projects at MBS spend a few months in incubation before launching, it’s incredibly refreshing to take a break. And of course, that’s nothing compared to projects in more traditional fields of engineering like mech or electrical, which typically take years to release.

So go out there and build something crude but useful.

[1] Letterpress is an insanely simple yet addicting game for iOS by Loren Brichter (a.k.a. atebits). If that name sounds familiar, it’s possibly because he’s also credited with the invention of the Pull-to-refresh concept and built the first version of what’s now Twitter’s official iPhone app.

This article was originally published on magneticbear.com

Since we started Magnetic Bear Studios about a year and a half ago, one of our core values was being as open as possible; our history, our process, our margins, our code.

Up to date, we have open sourced 10 internal projects on github. In 2013, we’re making open source an integral part of our company process.

To start off this wave of openness, we’re publishing our main company website at github.com/magneticbear/magneticbear.com. By the way, the site is based on a wonderful open source framework called docpad.

To help in our efforts to support the open-source community, we’ll be releasing some of our internal, currently closed-source projects, at the rate of one every month or two.

Finally, over the next few weeks, the MBS team will also be writing some blog articles here to document and publish some of the lessons we learn building mobile apps for startups from around the world.

We’ll let you know when we have more open goodness to share with you!

PS: There’s a lot more to open source than code. We’ll be making an effort to share everything from our networking stack to our contract lifecycle to some app design freebies.

Gig monthly

What?

There was a time when I played sax at local restaurants, corporate gigs, heck I even recorded an album with my brother that sold pretty decently.

How?

I’ve got a bassist, drummer and guitarist lined up. I’m approaching several of the bars/restaurants I used to play to set up some gigs.

Learn Japanese

What?

Christine and I will be learning Japanese this year. Our goal is to reach survival-in-Japan level by the end of the year.

How?

I bought all 3 levels of Rosetta Stone Japanese today. 3x 20 minutes and an hour-long session with Christine once a week.

Get featured on Hacker News

What?

I’d certainly like to refine my writing abilities and this is a stretch goal to accomplish that.

How?

Blogging here and on the MBS Labs website weekly.

Run a 3:30 marathon

What?

I’m not in the shape I’d like to be. I ran a 4:00 marathon last year and I can already run a 1:30 half marathon so this is the next logical step.

How?

Following the RunKeeper training plan. Track my progress on my RunKeeper profile.

Bike daily

What?

Starting on February 1st (in the snow for an added challenge). This doesn’t apply to days I have to drive.

How?

I’m buying a bike and doing it!