Exporting a project for iOS

Choose the export result

application/export_project_only defaults to false. For a first launch, starting with the Xcode project makes build and signing failures easier to distinguish. An .xcodeproj does not imply a finished .ipa, and an .ipa does not imply App Store acceptance.

Prerequisites

• A Mac with a full Xcode installation, the required iOS SDK and target-device support. Open Xcode and complete initial setup. Command Line Tools alone do not provide the iPhoneOS SDK.
• Templates for your Reckfell 1.0.0 build: the exporter looks for ios.zip. Custom templates use custom_template/debug and custom_template/release. Version, modules and .NET variant must match the project; an editor archive does not replace export templates.
• An Apple Account and signing Team. Personal-device testing and distribution have different Apple requirements; choosing a Team does not enable every delivery method. Running through Xcode.
• A project that runs in the editor. For C#, resolve ordinary build errors first, then separately validate mobile AOT publishing.

Use macOS for this complete workflow. The current .NET editor rejects Apple Embedded export configuration on other hosts. A non-.NET editor can leave an Xcode project with a warning instead of an .ipa; that is not an application build on Windows/Linux.

Configure an iOS preset

1. Add iOS in the project export dialog.
2. Set application/app_store_team_id to the Team ID rather than the developer's display name. It is required even for project-only export. Set a stable application/bundle_identifier, such as com.yourstudio.yourgame, matching your signing configuration.
3. Review application/targeted_device_family: iPhone, iPad or both. application/min_ios_version defaults to 15.0; actual requirements also depend on SDK, renderer and libraries. A preset number does not establish a launch on that iOS version.
4. For a first launch enable application/export_project_only. Create a separate output directory outside the project and export under a simple name such as Game. Do not mix output with source or hand-edited Xcode files: re-export cleans parts of the previous output.
5. Open Game.xcodeproj, keeping the generated .pck, application directories and XCFramework nearby. Do not move the .xcodeproj alone without its dependencies.

On the Mac, inspect the selected Xcode and available SDKs:

xcode-select -p
xcrun --sdk iphoneos --show-sdk-path
xcrun --sdk iphonesimulator --show-sdk-path

If the path points to /Library/Developer/CommandLineTools, select the full Xcode installation in its Command Line Tools setting and repeat the check. Successful output does not validate signing, templates or C#.

Run on a device

In Xcode select the application's scheme and connected device. Assign the correct Team and check Bundle Identifier in Signing & Capabilities. If using Xcode automatic signing, allow it to prepare the required signing assets. Then use Product > Run. If the device requests it, enable Developer Mode using Apple's instructions.

Test the main level, touch input, audio, background/resume behavior and user:// saves. For camera/microphone access provide meaningful privacy/camera_usage_description and privacy/microphone_usage_description; OS permission does not replace enabling the required module. Review third-party SDK permissions, privacy manifests and native dependencies separately.

Device and Simulator are different platforms even when both use arm64. They need corresponding XCFramework variants. Current iOS Simulator build sources disable Metal and Vulkan; a Compatibility/OpenGL path is provided when a matching template exists. Simulator launch does not establish real-device rendering, performance or features. Running iOS applications on Apple silicon is not a universal bypass for these requirements.

C#: validate AOT separately

iOS support in the current .NET exporter is marked experimental. The SDK enables PublishAot, PublishAotUsingRuntimePack and UseNativeAOTRuntime. The export plugin publishes device and simulator variants, then generates <assembly>_aot.xcframework. This differs from running C# in the desktop editor.

Check NuGet/extension dependencies for AOT/trimming compatibility and iOS support. Do not assume desktop-JIT dynamic code generation is available. Resolve dotnet publish, Failed to 'lipo' simulator binaries and Failed to generate xcframework failures before signing: changing Team cannot fix a missing library or AOT error.

Project-only mode does not skip generating C# dependencies. Retain necessary publish files; generating an .xcodeproj does not make them optional.

Release and re-export

After device validation, make a separate release export with Export With Debug disabled. For built-in archiving review debug/release settings: application/export_method_debug defaults to Development, while application/export_method_release defaults to App Store. Profiles and identity must match the selected method and Bundle Identifier. Keep real signing credentials out of examples and repositories.

Distinguish ARCHIVE SUCCEEDED from EXPORT SUCCEEDED in built-in build logs. Inspect the actual fresh .xcarchive/.ipa, output timestamp and full log: an old file or final process code alone does not establish success at every stage. Publishing/TestFlight use a separate Apple distribution workflow.

Game-resource changes require re-export. Preserve necessary Xcode edits separately: generated directories are not permanent source storage. Native integration is covered in iOS plugins, and template building in compiling for iOS.

Review boundary: this workflow was reviewed against the exporter, iOS configuration, C# plugin and Reckfell 1.0.0 SDK. No iOS export, iOS AOT, Xcode, signing, installation or device/simulator rendering was performed on this Windows host. Those remain validation steps for your build.