When I publish an update to my app, several files are auto generated/updated:
./xxx.app.dSYM.zip
./android/app/src/main/assets/shell-app.bundle
./android/app/src/main/assets/shell-app-manifest.json
./ios/xxx/Supporting/shell-app.bundle
./ios/xxx/Supporting/shell-app-manifest.json
is it safe to git update-index --assume-unchanged those files, or should I commit them every time?
I’m using the git flow style, so I would merge the branch via a PR and then publish the app from development/master, and an additional commit on those branches feels dirty.
What do you do with them?
1 Like
Does really no one have that issue in their codebase?
Still looking for an answer 
I’m wondering this as well - particularly with the manifest files, since some are needed for building the app store version packages
So it might be awful practice, but every time I run expo publish, I then delete the resulting files from the git repo. They’ll get regenerated anyway. And if I need to go back, fastlane has got my back with git tags or expo publish:history / expo publish:rollback…
Still kind of amazed that no one chimed in on this topic xD
That makes sense - I was thinking it might be a problem that the manifest files don’t exist as we won’t be able to build an apk/ipa without them, but actually it is necessary to publish before doing that anyway, assuming there were any JS changes (else these won’t be reflected in the app store version). So I suppose it’s a positive thing that it stops you building without publishing each time
Odd indeed! We must have missed the memo 
For a long time, I deleted those files and added them to .gitignore. You could think of them simply as “temp” files for your build- that’s the JS that gets bundled into your app for offline first load (plus the manifest which tells your app what your slug/ release channel is). So, it ends up in your APK/ IPA, so not like you’re losing it, really.
More recently, I moved to a system where I create a branch on each build/ release. My process creates the branch, publishes (which updates those files), then removes the files from .gitignore and commits them. So, my master stays clean, but I have those files archived somewhere still. This has been nice because I can do a production publish/ build, then do a test publish/ build (which would again change those files), then go back to doing production builds without having to republish.
Again, it wasn’t a big deal that I wasn’t committing those files, but committing them somewhere (not master) has been convenient.