iOS configuration, signing and release

Reference for the files delivered in Main_File. Documentation updated 22 September 2026. Examples use fictional IDs and balances; replace them with values from your installation.

Mac and project preparation

Build iOS on macOS with Xcode and an Apple Developer team. Use a Flutter SDK compatible with this package's pubspec/lockfile and a supported Xcode version accepted by Apple at upload time. Check Apple's submission requirements before release; SDK requirements change.

Project-specific status: the supplied ios/Runner/Info.plist is a starter configuration and does not include microphone/photo purpose strings or Google URL schemes; this package also has no committed Podfile. Complete the steps below on the Mac before claiming a tested iOS release. The documentation update itself was prepared on Windows and does not establish that an IPA has been built or accepted.

flutter doctor -v
flutter pub get
open ios/Runner.xcworkspace

If CocoaPods is required by the selected Flutter/plugins, let Flutter prepare the iOS dependency setup. If Podfile is still absent, generate an iOS scaffold in a separate temporary Flutter project using the same SDK and merge the generated Podfile/settings into this project after reviewing the differences. Do not replace the entire ios directory or overwrite your Firebase/signing changes. Run pod install from ios once that Podfile exists, then reopen the workspace.

Bundle ID and Xcode target

  1. Register an explicit App ID in your Apple developer account, for example com.yourcompany.appchat.
  2. Create the app record in App Store Connect with that ID.
  3. In Runner.xcworkspace select the Runner target. Set its Bundle Identifier for Debug/Profile/Release, Display Name, Version and Build.
  4. Set a deployment target supported by the installed plugins. Check both project/target settings and Podfile if used; the highest plugin minimum wins.
  5. Replace AppIcon/launch assets in Runner/Assets.xcassets, then verify them on a physical device.

Reference: Flutter iOS release guide.

Certificates and provisioning profiles

Automatic signing: add your Apple account in Xcode Settings → Accounts; select the correct Team under Runner → Signing & Capabilities and enable Automatically manage signing. Use your team's development identity for device testing. Xcode manages the matching profile; capabilities must match the registered App ID.

Manual signing: create an Apple Distribution certificate, keeping its private key in your Mac keychain. In Certificates, Identifiers & Profiles create an App Store Connect distribution profile for the exact explicit App ID and certificate, download/install it, then select it in the Release signing/export settings. A certificate without its private key cannot sign. If transferring signing to another Mac/CI, securely import the certificate and private key together; never ship these in Main_File. Renew expired profiles/certificates and regenerate profiles after capability changes. See Apple profile creation and manual distribution signing.

Firebase, permissions and AppChat services

  1. Register the chosen iOS bundle ID in your own Firebase project. Generate lib/firebase_options.dart using FlutterFire configuration for iOS/Android, and add GoogleService-Info.plist to Runner in Xcode with Runner target membership. Follow Firebase Flutter setup.
  2. Configure Google sign-in's reversed client ID URL scheme from your own plist in Runner URL Types. Do not reuse Android client IDs as the iOS URL scheme.
  3. For push notifications, enable Push Notifications in Signing & Capabilities and configure an APNs authentication key in Firebase. Add Background Modes → Remote notifications if your notification delivery requires it. Test on a physical iPhone.
  4. Add meaningful privacy strings to Info.plist for features used: NSMicrophoneUsageDescription for live voice/voice messages; NSCameraUsageDescription for capture; NSPhotoLibraryUsageDescription for library reads, and NSPhotoLibraryAddUsageDescription only when saving to the library. Example microphone purpose: “Use your microphone to speak in live voice rooms.” Do not request permissions for removed features. See Apple's photo-library key.
  5. Configure HTTPS API and secure socket endpoints. The shipped SocketManager currently constructs http://; update its URL construction for your TLS deployment before device testing. Changing only APPCHAT_SOCKET_PORT is insufficient.
  6. Create consumable App Store products matching recharge_packages.ios_product_id. Complete backend Apple receipt configuration from the Apple In-App Purchase section of index.html. Test receipt verification and exactly-once wallet credit in sandbox.

Build and upload

Use the same five deployment defines as Android, with your actual endpoints/key. Increase the build number for each uploaded build.

flutter build ipa --release --build-name=1.0.1 --build-number=2 \
  --dart-define=APPCHAT_API_BASE_URL=https://api.example.com/ \
  --dart-define=APPCHAT_API_KEY=YOUR_SHARED_APP_KEY \
  --dart-define=APPCHAT_SOCKET_HOST=socket.example.com \
  --dart-define=APPCHAT_SOCKET_PORT=443 \
  --dart-define=APPCHAT_SHARE_BASE_URL=https://example.com/share

The archive is produced under build/ios/archive and exported IPA under build/ios/ipa. In Xcode Organizer validate the archive, resolve signing/entitlement errors, then choose Distribute App → App Store Connect and upload. Alternatively upload the exported IPA using Apple's Transporter. Wait for App Store Connect processing and inspect any reported errors before selecting the build. See Flutter archive outputs and Apple build uploads.

TestFlight and App Store Connect submission

  1. Distribute the processed build to TestFlight testers. Test login, room entry/audio, reconnect, seat controls, gifts, recharge, store purchase, VIP, notifications, account deletion and app relaunch.
  2. Prepare the version's real screenshots, description, support/privacy URLs, age rating, privacy disclosures and export-compliance answers for your actual services.
  3. Select the tested build and applicable in-app purchases; supply App Review contact/access instructions and a working review account where required.
  4. Review the submission items, add the version for review, then submit to App Review. Choose the intended release method. Uploading an IPA alone does not submit a release.
  5. Resolve review feedback, increment the build if the binary changes, retest, and submit the corrected version.

Reference: Apple submission workflow. Account-specific privacy, purchase and login requirements must match the buyer's deployed app; neither a CodeCanyon purchase nor this guide guarantees store approval.