Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

CI never compiles anything Apple, so the iOS and macOS targets can break unnoticed

Open
  • Is something wrong?
#402 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
65/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
dart, flutter, github-actions, rust
Domain
ci-cd, mobile

Research direction

Start with .github/workflows/ci.yml and compare its existing Flutter and Rust jobs; then read ./scripts/frb-generate.sh and the proposed Apple build command. Add a macOS CI job gated on the specified paths, and decide how it should handle tracked-file changes from Flutter and CocoaPods. Done when the iOS simulator build runs successfully in CI without signing secrets or leaving an unintended dirty tree.

Written by the indexing model from the issue text.

Description

Problem

.github/workflows/ci.yml runs the Rust job on ubuntu-latest, the Flutter analyze/test job on ubuntu-latest, and a web build. No job ever compiles the iOS or macOS target, and there are no other workflows that do.

So nothing verifies that the Apple targets still build, and nothing catches a platform-specific regression. Two concrete examples found this week, both of which a compile-and-lint job could plausibly have surfaced, and neither of which anything would catch if reintroduced:

  • ios/Runner/Runner.entitlements existed but was referenced nowhere in project.pbxproj, so Xcode never read it (#399). If that setting is dropped again, CI stays green.
  • ios/Runner/Info.plist carried no NSCameraUsageDescription while mobile_scanner is a dependency, so the app was terminated by the OS on first camera access (#398).

Unlike the web target — which is guarded both statically (test/web/pages_bundle_test.dart) and at runtime (test/web/smoke/smoke.mjs) — Apple has no equivalent, not even a compile check.

Evidence that this has already cost something

Until last week, ios/Runner.xcodeproj/project.pbxproj contained no CocoaPods integration at all: no Pods group, no [CP] Check Pods Manifest.lock phase, no baseConfigurationReference. pod install writes all of that on its first run, so no one had ever built the iOS target. Neither ios/Podfile.lock nor macos/Podfile existed either.

The target does build (see the baseline in #118) — it simply built for the first time in a long while, and nothing would have told anyone if it had stopped.

Proposed scope

A macos-latest job in ci.yml, gated on paths that can affect it (ios/**, macos/**, rust/**, pubspec.yaml):

  • install the pinned Flutter (FLUTTER_VERSION) and Rust toolchains, add aarch64-apple-ios-sim
  • run ./scripts/frb-generate.sh (lib/src/rust/ is gitignored and produced on the fly, as the existing jobs already handle)
  • flutter build ios --simulator --no-codesign — no signing identity needed, so no secrets are required

A simulator build exercises the whole chain that actually breaks: CocoaPods resolution, the cargokit script phase that cross-compiles the Rust core, and the link into rust.framework. Cold, it takes about 3 minutes on a GitHub macOS runner.

Two things worth deciding when implementing it:

  1. flutter build ios rewrites tracked files. It bumps ios/Podfile from platform :ios, '12.0' to '13.0' (printed as Upgrading Podfile), and pod install injects its integration into project.pbxproj, contents.xcworkspacedata and the ios/Flutter/*.xcconfig files. A naive job leaves a dirty tree. Either commit the 13.0 bump deliberately — it is the value the Runner target already declares — or have the job tolerate the diff.

  2. Whether to also add a macOS desktop build. macos/ is present and its project.pbxproj already sets CODE_SIGN_ENTITLEMENTS, but macos/Podfile does not exist yet, so that target has likely never been built either. Possibly a separate issue.

This is deliberately scoped to a compile gate. Running tests on a simulator, or building for a device, both need signing material and are a larger conversation — the point here is simply that today the Apple targets are entirely unguarded.

Dominant language
Dart
Stars
11
Forks
9
Avg merge
13h 4m
Merged PRs (30d)
259

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MostroP2P/app

All issues in MostroP2P/app

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.