DEV Community: Utku Y.

I Built a macOS App to Automate the Most Boring Part of Shipping an App

Utku Y. — Thu, 03 Sep 2026 22:01:52 +0000

Shipping an app globally is exciting. Managing its App Store metadata in 28 languages is not.

Every time I pushed a new version of my app, I had to:

Open App Store Connect in the browser
Click through every single locale
Copy-paste "What's New" text into each one
Write the same description in English, then somehow handle German, Japanese, Arabic…
Generate screenshots for 5 device sizes × 28 locales = 140 images
Upload all of them manually

I'm one person. This was eating 4–6 hours per release. So I built a tool to fix it.

What is Lookalization?

Lookalization is a macOS app for indie developers that handles two things:

• xcstrings management — browse, edit, and AI-translate all your in-app localization strings directly, without touching Xcode
• App Store Connect metadata — edit descriptions, keywords, what's new, and promo text for every locale, all from one place

Version 1.6 just shipped, and it adds the piece I was missing most: full App Store Connect integration with AI translation and automated screenshot upload.

⸻

What's new in v1.6

App Store Connect sidebar

Connect once with your ASC API key (stored securely in Keychain). Your apps and versions load into the sidebar. Pick a version, and all your localizations are right there — editable, with live character counts and limit warnings.

No more browser tabs. No more copy-pasting between windows.

One-click AI translation

Each metadata field (description, keywords, what's new, promotional text) has a ✨ button next to it. Press it, and Lookalization translates that field from your source locale to every other locale simultaneously — using Claude via AIProxy under the hood.

It runs in parallel, so 28 locales take roughly the same time as 1.

Screenshot generator + batch upload

This is the part that took the most time to get right.

The flow:

Write a headline and subtitle in your language
Pick a device size (iPhone 6.9", 6.5", iPad 13" Pro, etc.)
Hit Generate & Upload All

Lookalization then:
• Translates the caption to all your ASC locales in one API call
• Renders a PNG for each locale using ImageRenderer
• Uploads each PNG to ASC via the screenshot upload API (reserve → chunk upload → MD5 commit)
• Shows live progress: Translating… → Uploading 4/28

What used to take an afternoon now takes about 90 seconds.

⸻

The technical bits (for the curious)

The screenshot upload to ASC is a 5-step pipeline that isn't well documented:

fetchScreenshotSets(localizationId) → find or create a set for the display type
reserveScreenshot(setId, name, size) → get upload operations + screenshot ID
uploadScreenshotChunks(data, ops) → PUT each chunk per the operations list
commitScreenshot(id, md5) → PATCH with uploaded: true + MD5 checksum

The MD5 is computed with CryptoKit.Insecure.MD5 and sent as a hex string. Without it, the commit silently fails — took me a while to figure that out.

For rendering, SwiftUI.ImageRenderer at @MainActor runs synchronously, which is exactly what you want when generating 28 images in a loop without any async confusion.

⸻

Who it's for

If you're a solo developer or small team shipping on the App Store with multiple language targets, the ROI on this tool kicks in within the first release.

It's available on the Mac App Store, free to try with a one-time Pro unlock.

Download Lookalization

Would love any feedback — especially from devs who've built similar pipelines or have ASC API war stories.

Turning SwiftUI Views into PDFs: A Quick How-To

Utku Y. — Tue, 22 Apr 2025 19:46:37 +0000

Need to generate a PDF from a SwiftUI view? Whether it's for sharing a report, creating a simple document, or any other purpose, SwiftUI's ImageRenderer offers a straightforward way to achieve this.

Here's a handy function that takes a SwiftUI view (ViewForPDFOutput in this example) and returns the URL of the generated PDF file:

struct Example: View {
    var body: some View {
        VStack {
            Text("demo")
        }
        .toolbar {
            buildShareButton()
        }
    }

    private func buildShareButton() -> some ToolbarContent {
        ToolbarItem(placement: .topBarTrailing) {
            ShareLink(item: getPdfUrl()) {
                Image(systemName: "square.and.arrow.up")
            }
        }
    }

    private func getPdfUrl() -> URL {
        let renderer = ImageRenderer(
            content: ViewForPDFOutput().frame(width: 500)
        )
        let url = URL.documentsDirectory.appending(path: "swiftui_output.pdf")

        renderer.render { size, context in
            var box = CGRect(x: 0, y: 0, width: size.width, height: size.height)

            guard
                let pdf = CGContext(url as CFURL, mediaBox: &box, nil)
            else {
                return
            }

            pdf.beginPDFPage(nil)
            context(pdf)
            pdf.endPDFPage()
            pdf.closePDF()
        }

        return url
    }
}

Note: It's important to give width to view which you want to make pdf.

.frame(width: 500)

SwiftData: MigrationStage.custom

Utku Y. — Thu, 26 Sep 2024 00:24:23 +0000

Hi,

I just wasted the whole day on MigrationStage's custom option.

My first advice is: Just care which document are you reading.. It can lead you in the wrong direction if document is missing, not totally correct, etc.

My app has one model and I call it with Story.
and it look likes this:

enum StorySchema_Vx_x_x: VersionedSchema {
    static var versionIdentifier: Schema.Version = Schema.Version(x, x, x)

    static var models: [any PersistentModel.Type] {
        return [Story.self]
    }

    @Model
    class Story {
        var title: String
        var story: String
    ...
    }
...
}

Now I have a new feature on app. However, due to the new design requirements I need to store Story.story as below.

struct StoryPage: Codable {
    let page: Int
    let story: String
}

Here's the problem:

How should I store story on last database design?

Replace var story: String with var storiesAsPart: [StoryPage]
Just add new parameter as var storiesAsPart: [StoryPage]?

First approach

Of course my first decision is first one! Because I think it's cleaner as code, easier to understand. There are no any other distracting variables. Bla, bla, bla...

Ta-daa, That's why I wasted my whole day.

I couldn't find proper way to achieve first option.
Every development I tried, came with another issue...

Second approach

I stopped to waste my time. Because this feature need to be release ASAP due to market-trending.

But still got errors. WHY!?

Because wrong usage of parameters...

Solution

Do you remember what I wrote earlier?
You have to check if it is correct; what you read, what you watch, what you listen...

I just found a video(1) and realize how should I use MigrationStage.custom.

Let's see how achieve to this migration.

enum StoryMigrationPlan: SchemaMigrationPlan {
    static var schemas: [any VersionedSchema.Type] {
        return [
            StorySchema_Vprevious_one.self,
            StorySchema_Vlatest_one.self
        ]
    }

    static var stages: [MigrationStage] {
        [
            migrate_Vprevious_one_TO_Vlatest_one
        ]
    }

    static let migrate_Vprevious_one_TO_Vlatest_one = MigrationStage.custom(
        fromVersion: StorySchema_Vprevious_one.self,
        toVersion: StorySchema_Vlatest_one.self,
        willMigrate: nil,
        didMigrate: { context in
            var stories: [StorySchema_Vlatest_one.Story]

            do {
                stories = try context.fetch(FetchDescriptor<StorySchema_Vlatest_one.Story>())
            } catch {
                fatalError("Failed to fetch stories: \(error)")
            }

            stories.forEach { story in
                story.storiesAsPart = [
                    StoryPage(page: 1, story: story.story)
                ]
            }

            do {
                try context.save()
            } catch {
                fatalError("Failed to save migration: \(error)")
            }
        }
    )
}

We have two additional parameters compared to MigrationStage.lightweight: the willMigrate and didMigrate closures.

I was already familiar with these closures, having read a lot about them, but as I mentioned before, it's important to know if the documentation is correct.

On that video (1), I got that the meaning of those closures.
willMigrate: Is commonly used for clean up data, prepare data to migrate etc.
didMigrate: Update new model variables as you wish.

In my case, I used didMigrate because I just wanted to fill new variable (because I know that's enough and it's okay).

Last words

I didn't waste anymore time on this feature. So, that's why I chose the quicker solution from my perspective.

I still believe that it's possible to achieve the first approach.

Need advice ~ Solo Dev. vs Design UI&UX

Utku Y. — Fri, 13 Oct 2023 19:22:13 +0000

Hi guys,

I'm just a solo developer and I have some ideas as side projects.
Some of 'em should run with team, some of 'em can be done as solo.
In anyway I need to design apps. Maybe as MVP I could go with only UX but I even need some advice about it.

Here's the point of this post, how could I get over design problem? I'm widely open for any tips.

XCode Code Snippet

Utku Y. — Mon, 05 Sep 2022 20:32:10 +0000

Hi friends,

Here is a little trick for XCode beginners.

Have you ever wonder how you can improve your coding speed?
Here is a basic trick for speed up, code snippet.

For example you are developing an app with SwiftUI, actually it doesn't matter SwiftUI, Swift, Obj-c, etc. You can even use snippets as creating comment blocks.

Here are steps for creating snippets.

Write block which will use as snippet

struct CodeSnippetDemo: View {
    var body: some View {
        Text("Hello, World!")
    }

    @ViewBuilder
    private func <#func name#>() -> some View {

    }
}

struct CodeSnippetDemo_Previews: PreviewProvider {
    static var previews: some View {
        CodeSnippetDemo()
    }
}

Select whole block
Then use menu as "Editor -> Create Code Snippet"
You can change information as you want. Top block field is name of snippet. Below block is holding platform informations. Trick point is "Completion" field. Because when you type what you used in completion field, XCode will ask you to complete with "that" snippet.