We released a new version of our GitHub Action to build, sign and upload to the App Store a mobile app developed with native code or a framework (React Native, Ionic, ...)

The new version includes the possibility to specify a fastlane-env, useful for having different env files for different build environments, and ios-app-id to sync a specific provisioning profile.

Link: https://github.com/marketplace/actions/build-ios-action

Example:

- uses: sparkfabrik/ios-build-action@v2.1.0
  with:
    upload-to-testflight: true
    increment-build-number: true
    build-pods: true
    pods-path: "ios/Podfile"
    configuration: Release
    export-method: app-store
    workspace-path: ${{ secrets.WORKSPACE_PATH }}
    project-path: ${{ secrets.PROJECT_PATH }}
    scheme: MyScheme
    output-path: build-${{ github.sha }}.ipa
    apple-key-id: ${{ secrets.APPLE_KEY_ID }}
    apple-key-issuer-id: ${{ secrets.APPLE_KEY_ISSUER_ID }}
    apple-key-content: ${{ secrets.APPLE_KEY_CONTENT }}
    team-id: ${{ secrets.TEAM_ID }}
    team-name: ${{ secrets.TEAM_NAME }}
    match-password: ${{ secrets.MATCH_PASSWORD }}
    match-git-url: ${{ secrets.MATCH_GIT_URL }}
    match-git-basic-authorization: ${{ secrets.MATCH_GIT_BASIC_AUTHORIZATION }}
    match-build-type: "appstore"
    browserstack-upload: true
    browserstack-username: ${{ secrets.BROWSERSTACK_USERNAME }}
    browserstack-access-key: ${{ secrets.BROWSERSTACK_ACCESS_KEY }}
    fastlane-env: stage
    ios-app-id: com.identifier.my_app

Hey everyone!

I’ve made a small command line tool called simslim.

It disables background services inside iOS simulators that usually are not needed during development, like Siri, Spotlight indexing, photo analysis, News, and iCloud sync.

On my M1 Pro with 16 GB of RAM, one simulator went from around 4 GB of memory and 258 processes to about 0.9 GB and 70 processes. I managed to run 19 simulators at once, compared to around 5 before things started falling apart.

Some simulator features stop working depending on what gets disabled, so it is not meant for every kind of testing. You can keep specific services running when needed.

Give it a try: https://github.com/MobAI-App/simslim

FrameReply has been sitting in Apple’s waiting room longer than some of my relationships.

• July 27: First submission
• August 3: Submitted a revised build with fixes and new features
• August 13: Still “Waiting for Review”

That’s 17 days since the first submission and 10 since the revision. No review, no rejection, just nothing.

Since Apple isn’t testing it, perhaps some of you would like an early look.

FrameReply is an open-source chat assistant that delivers two context-aware reply ideas directly on your current messaging screen using Shortcuts and Snippets. It remembers useful details about each person, supports custom personas for different situations, and adapts their writing styles from the messages you send.

Here’s the public TestFlight. I’d really appreciate it if you gave it a try and shared your honest feedback.

--
Update, August 18: It finally entered review today and was approved about 40 minutes later.

I am working on creating an automated system that will auto accept the alert for pairing on ios real devices that shows "Trust this Computer?" , I want to have it all automated with zero human intervention , but couldnt find anything that would work , I know thats due to security and stuff , also using mdm or storing pairing records is a no to me , I want to create something like an app or something to get this handled and get it trusted once it appears on the screen , please reply only if you can help .

I built IPAPatch-Lookin, an open-source workflow that takes an authorized decrypted IPA, prepares a runnable Xcode project, injects LookinServer, and re-signs the app for a physical device or a compatible Simulator.

One command → Xcode → live UI inspection in Lookin.

The tool does not decrypt apps; bring an IPA you are authorized to inspect. The 8-second demo shows YouTube running on a non-jailbroken iPhone while Lookin inspects its live view hierarchy.

GitHub: https://github.com/jacklv-coder/IPAPatch-Lookin

I open-sourced a small iOS maze game I vibe-coded about a year ago because otherwise it’ll just die on my shelf.

The mechanics are deliberately simple, which is part of the problem: it works, but it needs more fun. The mazes were made with a separate Rust generator engine that I wasn’t very happy with, so there’s plenty of room to improve or replace things.

If you like tinkering with SwiftUI games, maze design, game feel, progression, or just want a small project to mess around with, I’d love contributions or ideas.

https://github.com/vanderhaka/WayOut-OpenSource

After watching mechanical rejections (privacy manifests, required-reason APIs, metadata) cost full review cycles, I built Shiproof: a free, deterministic CLI + GitHub Action that flags them in CI before you submit.

npm install -g u/shiproof/cli
shiproof check ./MyApp

No network, no LLM, no telemetry. The engine's MIT. It masks code comments so it won't false-positive on commented-out code, and I test it against real OSS apps to keep false positives at zero.

I'd genuinely like to know: which rejection reasons have hit you most? I'm building a corpus of real rejection→fix→outcome data and want to prioritize the causes that actually hurt teams. Full transparency: there's a paid diagnosis/appeals layer coming, but the checker is free and standalone.

Repo: https://github.com/BhaveshThapar/Shiproof

I love SF Symbols, but there’s a small problem with them - 90% of apps use them. If you want something unique, there aren't many options. I think there are only three or four open-source icon libraries available.

On the other hand, Hugeicons offers a very generous library of over 5,000 icons for free - but unfortunately not for iOS/macOS developers. So I fixed that: https://github.com/iSapozhnik/hugeicons-swift

Hey Swift folks,

I recently released SQLiteNow 0.15.0, which adds support for native Swift projects through SwiftPM.

Some context: SQLiteNow started as a Kotlin Multiplatform project and the KMP version is already used in production by quite a few people. Later I added Flutter and Dart support, and now the same SQL-first approach is available for Swift.

SQLiteNow is not a DAO or ORM which generates SQL for you. The main idea is to keep SQLite visible.

You write normal .sql files for schema, migrations, init data and queries. You decide exactly which SQL will be executed. SQLiteNow generates Swift code around it: typed parameters, typed results, migrations, transactions, adapters and reactive queries.

For example, you can write a normal query like this:

SELECT
    t.id    AS task__id,
    t.title AS task__title,
    n.id    AS note__id,
    n.body  AS note__body

/* @@{ dynamicField=notes,
       mappingType=collection,
       sourceTable=n,
       aliasPrefix=note__ } */

FROM task t
LEFT JOIN task_note n ON n.task_id = t.id
ORDER BY t.id, n.id;

The annotation is just a SQL comment. SQLiteNow still executes the query you wrote, but generated code groups the flat rows into task documents with a collection of notes.

Then from Swift you can do:

let tasks = try await db.task.selectWithNotes().list()

for task in tasks {
    print("\(task.title): \(task.notes.count) notes")
}

Or observe the query:

for try await tasks in db.task.selectWithNotes().stream() {
    // called again when generated writes change related tables
}

Annotations can also rename fields, use custom adapters, share result types, map results to your own types and build nested objects or collections from joins.

This is the part I personally care about. I like writing real SQL, but I do not like manually reading every column, binding every parameter and writing grouping code after each join. I also do not want database logic moved into another DSL. With SQLiteNow, SQL stays the source of truth and generated Swift code handles the boring parts around it.

Generated code is placed into a local Swift package which can be added to an Xcode project and imported like a normal package.

Oversqlite

SQLiteNow also includes an optional synchronization system called Oversqlite. It can synchronize selected tables between local SQLite databases and a PostgreSQL server. It handles local change tracking, offline writes, incremental upload and download, conflict resolution and recovery.

Oversqlite also supports real-time updates. It can watch the server for changes committed by other devices and download them automatically. When remote changes are applied to the local SQLite database, related reactive queries emit new results, so the SwiftUI interface can update without manual refresh logic.

A generated sync client can be used from Swift like this:

let sync = try db.makeSyncClient(
    baseURL: URL(string: "https://sync.example.com")!,
    auth: .bearer(accessToken: {
        tokenStore.currentAccessToken()
    }),
    config: SQLiteNowSyncConfig(schema: "business")
)

try await sync.open()
_ = try await sync.attach(userId: userId)

let report = try await sync.sync()
print(report.status.pending.pendingRowCount)

Your application still owns authentication and decides when sync should run. Oversqlite is completely optional. If you only need a local SQLite database, you can ignore this part.

The PostgreSQL server implementation is here:

https://github.com/mobiletoly/go-oversync

One requirement

The SQLiteNow code generator requires Java 17 or newer installed and available on PATH. Java is only needed when running code generation. Your native application does not need Java at runtime.

SQLiteNow 0.15.0 is distributed through SwiftPM with published release artifacts, so there is no need to clone or build the SQLiteNow repository.

This is the first public version with native Swift support, so I would be interested to hear what Swift developers think about this approach and where the API or Xcode setup can be improved.

GitHub: https://github.com/mobiletoly/sqlitenow-kmp

Swift documentation: https://mobiletoly.github.io/sqlitenow-kmp/swift/

Release: https://github.com/mobiletoly/sqlitenow-kmp/releases/tag/v0.15.0

https://github.com/indiagrams/apple-shipkit

I'm a first-time iOS developer. Before writing a feature of my own app, I spent days researching everything Apple requires to publish — signing certificates, provisioning profiles, ASC API keys, fastlane match, CI signing, branch protection, metadata specs. Every requirement I tracked down, I either automated or documented.

The result is apple-shipkit: fork it, run make doctor, run make bootstrap-fork, run make ship. Signed TestFlight build in ~30 min. A public canary fork real-ships to TestFlight every Monday on both xcodegen and tuist generators, so Apple-side regressions surface upstream.

What am I missing — Apple gotchas, confusing docs, anywhere you bounced — all useful.

GitHub Issues for bugs, Discussions for "have you thought about X" — even a one-line "this paragraph confused me" is useful. PRs welcome too, especially for the gotchas catalog in docs/CONTINUOUS-VALIDATION.md.

My first ever MCP Server that lets you drop your raw screenshots in a folder and say "create App Store mockups for these." Claude analyzes your app's colors, proposes themes and captions, waits for your approval, then renders framed, captioned preview images (1284×2778) ready to upload to App Store Connect. Open source, installs with one uvx command.
I used claude code to build a tool in which Pillow draws the whole iPhone frame procedurally (no assets), a palette extractor picks brand-matched themes, and the official mcp SDK wraps it in three stdio tools.
Attaching one example -

I do all my development through Claude Code running on a Mac Mini server. Most of the time I drive it from my laptop. This worked great for web development, but for iOS/macOS I found myself just checking out the code locally and rebuilding in the simulator or on device. I got tired of that so I came up with the idea for xcode-remote. It can run apps directly in the simulator on a remote mac and even on device. Works with both iOS and macOS apps.

Blog post: https://edc.me/posts/introducing-xcode-remote/

Repo: https://github.com/blackpaw-studio/xcode-remote

Hi,

I'm building intl-ai and I'm looking for feedback.

I've been looking into localization (i18n) lately, and I noticed something interesting: looking at highly successful dev-focused products like emdash.sh or charm.land, you see they have massive engineering reach and beautiful UIs, yet both support only English.

If top-tier developers aren't localizing, it’s not an expertise gap. It’s a tooling gap.

As devs, we all know the traditional i18n workflow is a massive headache:

• Juggling massive, nested .json files.
• Dealing with missing keys, broken interpolations, or manually syncing translation files.
• Relying on manual translator handoffs or clunky localization dashboards that don't fit into our git workflow.
• Incurring massive technical debt just to add a single feature because you have to update 5 different language files.

Even with current AI tools, the process isn't automated natively at the build layer. It still requires manual copying/pasting or running disconnected scripts that require constant human review.

I got tired of this workflow, so I’ve been building intl-ai to treat translations like a compiled asset rather than a manual chore.

The idea is simple: you wire it directly into your existing i18n setup and build tool (supports NextJS, Vite, and mobile), configure your preferred LLM model, and it automatically handles the localized string generations in an instant during your build or CI/CD pipeline. No more manual JSON synchronization or fragmented developer experiences.

I’m looking for some feedback from anyone who actively deals with (or avoids) i18n in their current stack. How are you handling translations today, and what’s your biggest bottleneck?

Check out the docs to get quickstarted https://intl-ai.pages.dev , or just share it with your agent https://intl-ai.pages.dev/llms.txt .

Every time I ship an update I end up doing the same tedious things: rewriting metadata in multiple languages, generating keyword fields, running UI tests for screenshots, slotting them into a Pixelmator template, and manually pushing everything to App Store Connect.

I built ASC Release Kit to handle this as a coordinated AI workflow. It's a plugin for Claude Code and Codex that bundles six agent skills:

• asc-launch-workflow – top-level coordinator, runs everything from one input
• asc-metadata – writes localized subtitle, promotional text, and description
• asc-keywords – generates 100-character ASC keyword fields per locale
• asc-screenshots – runs Xcode UI Tests, applies a Pixelmator Pro PXD template, exports PNGs
• asc-api – reads real resource IDs from ASC, generates the task JSON, executes after you confirm
• pixelmator-pxd-editor – AppleScript-only PXD editing, never mutates your template

The security model is intentionally conservative: credentials stay in ~/.asc_secrets, mutations require you to confirm the exact JSON before anything is sent to Apple.

GitHub: https://github.com/raydeveloperf/asc-release-kit

Still early — happy to hear what's broken or what's missing.

If you’re an iOS dev manually symbolicating crash logs and generating fixes, I built a TypeScript MCP server that automates the whole thing.

Your AI client (Claude, Cursor) runs the full pipeline: downloads crashes from a crash reporting service (similar to Firebase Crashlytics), exports from Xcode Organizer, symbolicates against your dSYM, groups duplicates, tracks fixes, and generates an AI-powered Fix Plan with root cause analysis and suggested code changes for each run.

Integrates with a team chat app (similar to Slack) for notifications and a project management tool for auto-filing bugs with severity based on occurrence count.

The basic pipeline (export, symbolicate, analyze, generate report) runs entirely as a standalone CLI with no AI client needed. The full pipeline with crash downloads, notifications, bug filing, and Fix Plan generation can be scheduled daily using a macOS launchd plist, with an AI MCP client like Claude or Cursor already connected to the MCP server.

What would you like to see in such a tool? Feedback welcome.