DockDash - App Release and Updates#

This is the single end-to-end procedure for preparing, notarizing, publishing, and testing a DockDash release. It follows the tested SoundDash release method, adapted for DockDash’s bundle identifier, signing keys, support repository, and Dock-specific checks. Follow the execution checklist from top to bottom. The reference sections afterward explain setup and why the order matters.

The production update feed is https://marcoue.github.io/dockdash-support/appcast.xml. Any Sparkle-enabled copy of DockDash can see a release as soon as this feed advertises it. A GitHub release marked Pre-release is still offered by Sparkle if it is in this feed.

SoundDash - App Release and Updates#

This is the single end-to-end procedure for preparing, notarizing, publishing, and testing a SoundDash release. Follow the execution checklist from top to bottom. The reference sections afterward explain setup and why the order matters.

The appcast at https://marcoue.github.io/SoundDash-Support/appcast.xml is the production update feed. Any Sparkle-enabled copy of SoundDash can see a release as soon as this feed advertises it. A GitHub release marked Pre-release is still offered by Sparkle if it is in this feed.

GenDash Folder Migration#

1. Preparation & Freeze#

• 1.1 Create the new project folder at /Users/marc/Xcode/GenDash.
• 1.2 Confirm the destination folder is empty before copying the project.
• 1.3 Close Xcode and any other application that may be watching or editing the project.
• 1.4 Confirm there are no unsaved changes in source files, localization worksheets, or documentation.
• 1.5 Record the current Git branch and working-tree status.
• 1.6 Resolve or document the current Git file-watcher warning before relying on the status check.

2. Copy the Project#

2.1 Complete Copy#

• 2.1.1 Make a complete filesystem copy of the project into /Users/marc/Xcode/GenDash.
• 2.1.2 Preserve the .git directory, hidden files, package directories, symlinks, file permissions, and localization bundles.
• 2.1.3 Preserve the Xcode project, workspace, app source, widget source, resources, entitlements, property lists, documentation, scripts, and localization files.
• 2.1.4 Keep the original project folder unchanged as a rollback copy.

2.2 Copy Verification#

• 2.2.1 Confirm the copied repository contains GenDash.xcodeproj and its workspace.
• 2.2.2 Confirm the copied repository contains both the GenDash app target and GenDashWidget extension target.
• 2.2.3 Confirm the copied repository contains the GenDash Localizations, Images, Appliances, Generators, Manuals, and scratch folders.
• 2.2.4 Confirm the copied repository contains AGENTS.md, .agents, MISSION.md, .gitignore, and the string catalogs.
• 2.2.5 Confirm the copied .git directory identifies the same repository, branch, and remote configuration.
• 2.2.6 Confirm the original project remains unchanged after the copy.

3. Xcode Relocation Validation#

3.1 Project References#

• 3.1.1 Open the copied GenDash.xcodeproj from /Users/marc/Xcode/GenDash.
• 3.1.2 Confirm the project navigator contains no red or missing file references.
• 3.1.3 Confirm the workspace opens normally and uses the copied project.
• 3.1.4 Confirm the shared GenDash and GenDashWidget schemes are available.
• 3.1.5 Confirm the Xcode project, workspace, and schemes contain no stale absolute references to the old folder.

3.2 Build, Signing & Runtime#

• 3.2.1 Confirm the main app target retains its original bundle identifier, signing team, entitlements, and property list settings.
• 3.2.2 Confirm the widget target retains its original bundle identifier, signing team, entitlements, and property list settings.
• 3.2.3 Build the main GenDash target from the new location.
• 3.2.4 Build the GenDashWidget target from the new location.
• 3.2.5 Run the app and confirm the widget and Live Activity integration still function.
• 3.2.6 Confirm moving the source folder has not changed device or simulator app data, Keychain behavior, or CloudKit configuration.
• 3.2.7 Do not export or import localizations as part of the folder move.

4. Project-Internal Absolute Path Audit#

4.1 Path Audit#

• 4.1.1 Search the copied project for references to the old project location.
• 4.1.2 Separate Xcode configuration references from scripts and historical recovery files.
• 4.1.3 Confirm the Xcode project, workspace, schemes, entitlements, and property lists are path-independent.
• 4.1.4 Confirm every approved operational script now locates the repository from its own location or the new project path.
• 4.1.5 Test each retained project script from /Users/marc/Xcode/GenDash.
• 4.1.6 Repeat the audit until no required project workflow depends on the old project location.

5. External Scripts, Aliases & Launchers Audit#

5.1 Inventory#

• 5.1.1 Identify the definition and location of the pushgen command.
• 5.1.2 Check shell aliases, shell functions, startup files, and PATH entries for references to the old Antigravity folder.
• 5.1.3 Check symlinks, launch scripts, Automator actions, Shortcuts, LaunchAgents, scheduled jobs, and other local launchers that may invoke GenDash tools.
• 5.1.4 Inventory repository scripts that use absolute paths or assume the old project location.
• 5.1.5 Classify each script or launcher as active, required, optional, or historical.

5.2 Approved Changes & Validation#

• 5.2.1 Update /Users/marc/Scripts/MacOS/lock_gendash.sh so its GenDash localization and string-catalog paths point to /Users/marc/Xcode/GenDash.
• 5.2.2 Update /Users/marc/Xcode/GenDash/AGENTS.md so its localization workflow and locked-file paths point to the new project location.
• 5.2.3 Update /Users/marc/Xcode/GenDash/.agents/skills/gendash-architecture/SKILL.md so its project file links point to the new project location.

6. Final Sign-Off#

6.1 Sign-Off#

• 6.1.1 Verify the active file-locking aliases resolve to the updated script and no active external configuration still references the old project path.
• 6.1.2 Record the changed files and the rollback method before marking the migration complete.
• 6.1.3 Mark the migration complete only after the original folder is no longer needed as a rollback copy.
• 6.1.4 Remove the original folder only as a separate, explicitly approved cleanup action.

7. MacBook Air Migration (Secondary Computer)#

7.1 Preflight#

• 7.1.1 Confirm the MacBook Air’s current GenDash project location, Git branch, working-tree status, local-only commits, and remotes.
• 7.1.2 Confirm the GenDash and Scripts migration commits are available on their remotes before pulling them to the MacBook Air.
• 7.1.3 Confirm /Users/marc/Xcode/GenDash does not already contain a project and preserve the current Air folder as a rollback copy.

7.2 Repository Relocation#

• 7.2.1 Choose the relocation method: move the complete existing checkout when local-only state exists; use a fresh clone when the checkout is clean and fully synchronized.
• 7.2.2 Create the new folder and relocate or clone GenDash into /Users/marc/Xcode/GenDash, preserving .git when moving the existing checkout.
• 7.2.3 Pull the latest GenDash changes in the new location.
• 7.2.4 Verify the branch, history, remotes, tracked files, and working-tree status.

7.3 Xcode and Script Validation#

• 7.3.1 Open the GenDash project or workspace from the new location and confirm both schemes and references are available.
• 7.3.2 Build the main app and widget once from the new location.
• 7.3.3 Pull or clone the /Users/marc/Scripts repository on the MacBook Air and confirm genl, genu, gens, and genx use the updated locking script.
• 7.3.4 Confirm pushgen remains unchanged because it serves the separate Obsidian/Hugo workflow.
• 7.3.5 Confirm no active workflow on the MacBook Air still depends on the old project path.

7.4 Sign-Off#

• 7.4.1 Keep the original MacBook Air folder until the new setup has passed validation.
• 7.4.2 Remove the original MacBook Air folder only as a separate, explicitly approved cleanup action.

App Store Submission Checklist#

1. Administrative & Legal#

• 1.1 Active Apple Developer Program Membership: Annual subscription required to distribute on the store.
• 1.3 App Store Connect User Access: Proper permissions for the team members managing the submission.
• 1.2 Facultative - I’ll start with the individual account - D-U-N-S Number: Unique identifier used by Apple to verify business entities for organizations.
• 1.4 Paid Applications Agreement: Signed contract required for apps with a purchase price or subscriptions, via https://appstoreconnect.apple.com/ (Demande TPS-TVQ fait 27 avril)
• 1.5 Banking and Tax Information: Verified details needed for Apple to process your earnings.
• 1.6 Public Privacy Policy URL: A web link detailing how you handle and protect user data. (https://github.com/marcoue/GenDash-Support/ and Privacy form in App store)
• 1.7 Export Compliance Documentation: Proof of clearance for apps utilizing specific types of encryption. (Via Info.plist file in Xcode)
• 1.8 Digital Services Act (DSA) Compliance: Mandatory legal registration for distribution within the European Union. (Opted out for now as it requires my personal home address)

2. Technical Requirements#

• 2.1 Latest Mandatory Xcode Version Build: The binary must be compiled with the current Apple-approved IDE.
• 2.2 Latest iOS SDK Compatibility: Ensuring the app supports current system APIs and frameworks.
• 2.3 App Privacy Manifest: A .privacyinfo file documenting the data types accessed by your code.
• 2.4 SHA-256 Certificate Support: Modern security standard required for app signing certificates.
• 2.5 64-bit Architecture Support: Technical requirement for compatibility with all modern iOS hardware.
• 2.6 Optimized Binary Size: Monitoring the final build to stay within cellular download limits. (When app is completed)
• 2.7 Bitcode Disabled: Adherence to modern standards where bitcode is no longer required for thinning.

3. Metadata#

• 3.1 App Name: The primary title of the application as it appears in search.
• 3.2 Subtitle: A secondary tagline used to summarize the app’s purpose.
• 3.3 Description: A full text overview of features and functionality for potential users.
• 3.4 Keywords: A hidden list of terms that improve the app’s search discoverability.
• 3.5 Promotional Text: A short, editable field to highlight news or limited-time updates.
• 3.6 Marketing URL: A link to your product’s landing page or company website.
• 3.7 Support URL: A direct link where users can go for technical help or FAQs.
• 3.8 Version Number and Build String: Incremental identifiers for tracking your releases and builds.
• 3.9 Category Selection: Tags that determine which store departments the app resides in.

4. Visual Assets#

• 4.1 App Icon: A 1024x1024 px image representing the app on home screens.
• 4.2 Screenshots for 6.7" Display: Visuals for the largest iPhone models like the Pro Max.
• 4.5 iPad Screenshots: Required imagery if your app is compatible with iPadOS.

5. App Review Information#

• 5.1 Demo Account Credentials: Login data provided to allow reviewers to access hidden features.
• 5.2 Review Notes: Extra instructions to help the reviewer understand complex workflows.
• 5.3 Reviewer Contact Information: Name and number for the person Apple should call with questions.
• 5.4 Hardware Requirements: Documentation of any external hardware needed for the app to work.

6. Privacy & Content#

• 6.1 Privacy Nutrition Labels: A summary of what data is collected and how it is linked.
• 6.2 Accessibility Nutrition Labels: A declaration of the app’s support for assistive technologies.
• 6.3 Age Ratings: A self-assessment used to determine content suitability for different age groups.
• 6.4 App Tracking Transparency (ATT) Prompt: The system-level request for permission to track user data.
• 6.5 Content Rights: Legal confirmation that you have the rights to use all displayed content.

7. Pricing & Availability#

• 7.1 Pricing Tier Selection: The defined cost for purchasing the app or in-app services.
• 7.2 Regional Availability: A list of specific countries where the app will be available.
• 7.3 Pre-order Status: A setting to allow users to sign up for the app before launch.
• 7.4 Release Methodology: A choice between manual, scheduled, or automatic publication.

8. Critical Alerts Entitlement & Implementation#

• Submit the “Critical Alerts Entitlement” Request Fill out the official Apple form providing a safety-based justification for why GenDash fuel/status alerts must bypass the mute switch.