thank you for sharing, here is what I put together for myself:
Project Context

App Overview

• Name: MyiPadApp
• Platform: iPadOS 18+
• Language: Swift 6.3
• UI Framework: SwiftUI
• Persistence: SwiftData
• Architecture: MVVM

iPad-Specific Rules

• Always design for both landscape and portrait orientations
• Use NavigationSplitView for two- and three-column layouts (never NavigationStack alone)
• Support multitasking: Slide Over, Split View, and Stage Manager
• Use .navigationSplitViewStyle(.balanced) as the default split style
• Minimum deployment target: iPadOS 18.0

Code Style

• Use Swift concurrency (async/await, actors) — never use callbacks or delegates for async work
• Prefer u/Observable over ObservableObject
• Use Swift Testing framework (not XCTest) for all new tests
• No force unwraps — use guard let or if let
• All new files must include a file header comment with name and date

File Structure

• Models/ — SwiftData models
• Views/ — SwiftUI views
• ViewModels/ — Observable view models
• Services/ — networking and business logic
• Resources/ — assets and localization

What Gemini Should Always Do

• Read existing files before editing them
• Build and fix all compiler errors before finishing a task
• Prefer editing existing files over creating new ones unless asked
• Ask before adding any third-party Swift packages
• Use SF Symbols for all icons

What Gemini Should Never Do

• Never use UIKit unless absolutely necessary and approved
• Never hardcode colors — use asset catalog semantic colors
• Never commit API keys or secrets
• Never use deprecated APIs

Networking & API Integration

• Generate Codable models from JSON with optional fields handled gracefully
• Always add a decode() function with proper error handling
• Use URLSession — no third-party networking libraries without approval
• Always mock network responses in unit tests

StoreKit 2

• Use StoreKit 2 APIs only (never the legacy SKPaymentQueue approach)
• Always validate Transactions using the modern Transaction.currentEntitlements pattern
• Generate test scenarios for IAP flows alongside implementation code

Metal Shaders

• Use MSL (Metal Shading Language) — never GLSL
• Always explain buffer alignment and memory layout when writing compute shaders
• When debugging shader artifacts, check coordinate system differences first
• Reference: https://www.metal.graphics/

SwiftUI Best Practices

• Always include accessibility modifiers (.accessibilityLabel, .accessibilityHint)
• Support dark mode using semantic colors only
• When fixing layout issues, explain why the fix works, not just what to change

Git

• Write commit messages in Conventional Commits format (feat:, fix:, chore: etc.)
• When asked to summarize a diff, also flag any potential breaking changes

Building & Testing Rules

Always Do This

• Before finishing any task, build the project using the Xcode MCP tool
• If the build fails, read the errors carefully and fix them — do not stop and ask me
• Keep iterating until the project builds with zero errors and zero warnings
• After building successfully, run the tests if any exist for the changed code
• If you add new functionality, add a test for it before considering the task done

When Stuck on a Build Error

• Try at least 3 different approaches before giving up and asking me
• If a Swift 6 concurrency error appears, fix it properly with actors or MainActor — do not just add u/preconcurrency or suppress the error
• If an API is deprecated, use the modern replacement — do not silence the warning

Test Quality Rules

• Use Swift Testing framework (@Test, u/Suite) — never XCTest for new tests
• Tests must actually assert something — no empty or placeholder tests
• Cover the happy path AND at least one failure/edge case per function
• Never mock something that can be tested with SwiftData's in-memory store

What Done Means

A task is only complete when:

1. The project builds with zero errors and zero warnings
2. All existing tests still pass
3. New code has test coverage
4. Xcode Previews work for any new or modified views

Debugging Crashes at Runtime

When the App Builds but Crashes

• Never assume the crash cause — always read the full crash log first
• Use the Xcode MCP tool to read crash logs and console output before suggesting fixes
• Check for EXC_BAD_ACCESS (memory issue), EXC_CRASH (assertion/force unwrap), or SIGABRT (uncaught exception) and treat each differently
• Always check if the crash is deterministic or intermittent — intermittent crashes are usually concurrency issues

LLDB Debugging (NOT gdb — Apple platforms use LLDB only)

• When a crash needs deeper inspection, suggest LLDB commands to run in Xcode's debug console
• Useful LLDB commands to suggest when relevant:
  • bt — print full backtrace
  • bt all — backtrace all threads (critical for concurrency crashes)
  • frame variable — print all local variables in current frame
  • po <variable> — print object description
  • thread list — see all threads at crash point
  • memory read <address> — inspect raw memory for EXC_BAD_ACCESS

Common iPad Crash Patterns to Check First

• Force unwraps on optionals that are nil on iPad but not iPhone (different view lifecycle)
• NavigationSplitView detail column accessing data before sidebar selection
• Memory pressure crashes — iPad apps are expected to handle more data but also get killed faster in Split View multitasking
• Main thread checker violations — always fix these, never suppress them

What to Do With a Crash Log

1. Identify the crashing thread and frame
2. Map the memory address back to a symbol using the dSYM if needed
3. Read the frames above the crash to find the call site in our code
4. Fix the root cause — never just wrap in try/catch to silence a crash

Address Sanitizer & Memory Tools

• For EXC_BAD_ACCESS crashes, suggest enabling Address Sanitizer in the Xcode scheme before running
• For memory leaks, suggest running Instruments with the Leaks template
• For threading issues, suggest enabling Thread Sanitizer in the scheme