My Efficient Process for App Version Updates

I ran through a series of updates (0.8.0, 0.8.1, and 0.8.2) in an app I'm working on. This reminded me that I should document my streamlined process for handling version updates efficiently. Having a systematic approach ensures consistency across all files and makes the process less error-prone.

Understanding Version Types First

Before diving into any update, I always take a moment to determine what type of version change I'm making:

• Is it a patch update (0.8.x)? These address bugs or minor improvements.
• Is it a minor update (0.x.0)? These typically introduce new features without breaking changes.
• Is it a major update (x.0.0)? These can include breaking changes or significant overhauls.

If I'm ever unsure, I pause and think it through. Getting this wrong can send incorrect signals to users about the nature of the update.

Creating a Standardized Build Number

For consistent versioning, I use a combination of a sequential build number and a timestamp:

1. First, I generate a timestamp with:

   date "+%Y%m%d%H%M"

   This produces something like 202405151236, capturing the exact date and time.
2. Next, I increment the integer in buildnumber.txt (e.g., from 8 to 9).
3. The full build number becomes: [incremented integer].[timestamp] (e.g., 9.202405151236).

Updating All Required Files

This is where consistency is crucial. I need to update the version information in multiple places:

1. Build Number File

In buildnumber.txt, I just update the integer value (e.g., 9).

2. Xcode Project File

In BarcodeApp.xcodeproj/project.pbxproj, I need to update:

• MARKETING_VERSION to the new version number (e.g., 0.8.3)
• CURRENT_PROJECT_VERSION to the full build number (e.g., 9.202405151236)

I make sure to update these values for all configurations (Debug/Release for all targets).

3. Info.plist File

In BarcodeApp/Info.plist, I update:

• CFBundleShortVersionString to the new version number
• CFBundleVersion to the full build number

4. Release Notes

In fastlane/metadata/en-US/release_notes.txt, I:

• Update the heading to "What's New in Version X.Y.Z"
• List all changes as bullet points
• Keep the thank you message at the bottom

5. App Review Notes

In fastlane/metadata/review_information/notes.txt, I:

• Update the version number in the opening line
• Describe key updates for the App Review team
• Maintain standard information like "No login required"

6. Promotional Text

In fastlane/metadata/en-US/promotional_text.txt, I highlight the most important new features while maintaining mentions of key existing ones.

Verification Before Committing

Before finalizing anything, I double-check that:

• All files have the correct version and build numbers
• The release notes and review notes accurately describe the changes

Proper Git Workflow

With everything verified, I follow a standard git workflow:

1. Commit all the changed files:

   git add buildnumber.txt BarcodeApp.xcodeproj/project.pbxproj BarcodeApp/Info.plist fastlane/metadata/en-US/release_notes.txt fastlane/metadata/review_information/notes.txt fastlane/metadata/en-US/promotional_text.txt
   git commit -m "Update to v[VERSION] (build [BUILD_NUMBER]): [BRIEF DESCRIPTION OF CHANGES]"

2. Create a git tag for the version:

   git tag "v[VERSION]"

3. Verify the tag was created:

   git tag -n | grep v[VERSION]

Conclusion

While this might seem like a lot of steps, having a structured process makes version updates much more efficient and less error-prone. I can usually complete the entire process in under 10 minutes, even for complex updates. The key is consistency – following the same steps every time ensures I don't miss anything important.

What's your versioning process like? I'd be curious to hear if you have any tips or optimizations I could incorporate into my workflow.

---