PNG-images turn blank/corrupted after build and archive - ios

I ran into a strange problem today, after renaming a couple of images in my app and making sure they work on a device as well as the simulator, I used Build and Archive as I always do to build my app to distribute to the testers.
However, this time I got strange reports from the testers saying the images were gone, so I installed the build on my phone and to my surprise they were gone as they said. Tried to do a clean and build again but no change.
When I open the .app archive I can clearly see that many, but not all, of the images have turned blank, they appear to be the same physical size on the disk and they also seem to have the correct height and with when I press space to preview them, I can't however open them with photoshop for example (the file-format module cannot parse the file).
This is very confusing and as I have to get the build ready for testing very soon I would very much appreciate some help in this matter.

Your source PNGs seem to be slightly off-standard or at least incompatible with Apple's pngcrush. Make sure you use a commonly well functioning tool for creating the PNGs - when in doubt reconvert/resave them.

Related

How to reduce archive size in iOS

So I have just shocked that I ran out of space in my Mac book, then I try to find out what really fills up my space. This machine is only used for iOS app development (react native 0.64), and one thing that I also tried to do is cleaning up the archives of my Xcode. To my shock, like every single archive is taking 1.5GB space, but the app itself only like 20MB in play store. So I guess every single archives also contains extra data that I'm not sure important or not.
another thing that I notice is that the app archiving can take around 30 minutes alone, while the android release build only take 3 minutes to build an the .apk size of android is only 30MB.
My question here is:
how to somehow reduce the space taken by archive?
if no. 1 doesn't work, how to auto delete archive after upload to TestFlight or play store?
is there a way to reduce the archiving time taken?
To delete unused XCode data in iOS, I am using DevCleaner (that is set to remove archives/build data every week automatically):
https://apps.apple.com/us/app/devcleaner-for-xcode/id1388020431?mt=12
you can delete this folder every now and again to get more space
/Users/user/Library/Developer/Xcode/DerivedData
use fastlane to make builds much faster and you can automate a whole bunch of processes
this tutorial is dated but I still use it as a reference
https://docs.fastlane.tools/getting-started/cross-platform/react-native/

Xcode crashed while renaming project - whole project broken

I wanted to release an app I worked on and quickly change the project name. I usually duplicate projects before doing things like this but this time - because this procedure always worked on Xcode as I found it way more reliable than e.g. Eclipse - I didn't, which I immediately regretted.
Opened Xcode again and now I am seeing this
I guess all the linking is gone now which is why Xcode doesn't "find" the files anymore. Renaming the remaining project stem to the old name gives
couldn’t be moved to because an item with the
same name already exists
and also manual renaming of folders won't work as the .xcodeproj is gone.
The project is written in Objective-C, and all the classes are still persistent, but the effort of adding all the xib's, referencing the outlets, setting architectures, etc will become the nightmare of my life. I do have a half-way recent backup but everything I did to make the app store-ready today will be gone.
Any ideas on how to rescue my project?
EDIT: What Xcode is now showing on the welcome screen is a project called "project" (literally) and it has the usual compass icon but with a white instead of a blue background referring to the path <project folder>/<new project name>/ and below that "white" project there is a folder icon with the new name pointing to <project folder>.
I also made a snapshot before, of course it now says "Unable to read snapshots" in the "restore from snapshots" window.
Ok what I now did is renaming ALL references from the old project name to the new one. I even changed file names. I used Xcode's CMD+SHIFT+F and TextWrangler's "replace" function and thankfully I still had the .xcodeproj from yesterday's backup so from there I could copy it into the new project and rename stuff. There are still some things that don't work perfectly, for example auto layout doesn't "stretch" contents over the screen (it stays on iPhone 4s size, even on 6 plus simulator), I needed to set the scheme again and Launch Images / Icons got lost but I can look over that. The only thing I am afraid of now is that the final build might miss out a symbol or something like that so I eventually have a corrupt file in the App Store, but man it's a beta version, how much worse can it get anyway?
Thanks to everyone recommending me to even backup the broken project, I did this even before you said it but because I think it's a valuable advice I wanted to put it in my answer as well.
It's a shame that stuff like this can happen, I've been backing up my work on a daily basis and my project never got corrupted - until now.

Determining if iOS frameworks are actually needed

I am rebuilding an App and at the same time paring it down of unnecessary code and it contains "required frameworks" that I think were left over from copying a previous app shell for building this app. How can I determine if a framework is actually needed. I thought I could just leave them off and build the app and then add them as required to let it build successfully but in the past that has not worked well to my surprise as I have built and tested a previous App without any additional frameworks added and the App built and ran just fine on simulators and actually devices only to find out at submission time I forgot to add the frameworks before submitting it.
I am trying to be proactive and only put in the ones I need. Some, like the MediaPlayer are definitely not needed and I can eliminate them already but some are harder to determine.
Curious if there was an easy way to figure this out.

CCParticleSystem and TestFlight build bug?

I'm not really sure if this question is answerable as I am completely puzzled by this. Maybe if someone had a similar issue and can maybe point something out?
So I used 4 different CCParticleSystem effects in my app which run perfectly fine when built and installed from xcode. However, when I build and upload for testflight and download to my device, one of the CCParticleSystem effects doesn't show up with the intended particle texture, but instead shows up as a square instead of the texture I provided.
All 3 other CCParticleSystem effects are working properly though, just not this one, which is puzzling me.
I used Particle Designer for all 4 particle effects.
Anyone have any issues like this? Thanks for reading.
In my experience there are a couple of things that can cause issues like this:
There could be a resource missing from your build that was present in a previous build. Sometimes builds from XCode to device ignore resource deletions and updates.
You can check for this by doing an uninstall from the device, a clean in XCode, and then rebuilding to see if that makes the XCode build consistent with the TestFlight build.
If that doesn't help, then check the target membership of your particle resource and verify that it has been included in every build target that it should be (if you have multiple build targets).
Note that as a general rule, it is a good idea to do a clean within XCode prior to building an archive for distribution. This should ensure that the archive is always built using the latest sources and resource files.

How do I reliably get Instruments 4.x to symbolicate?

I have a bit of a dilemma — no matter what I do, I cannot get Apple's Instruments.app to symbolicate any of the included instruments while I'm profiling on my devices (it works OK in the iOS Simulator).
I've tried just about everything I can think of, including:
Checking that I'm actually building a dSYM
Switching between Debug and Release build schemes
Making sure that the signing certificate being used in my Development cert
Adding and removing my Derived Data folder from Spotlight's Privacy list
Clean & Build before profiling
Removing the Derived Data folder before building and profiling
I'm not sure where to go from here — I had symbols for an hour or two earlier in the week, but I just can't get them to show up at all anymore. It would be great to figure out what the mystical incantation is to make Instruments always find my app's symbols.
In the File menu there is an option for Re-Symbolicate Document. Choosing this, you can find your binary in the list and use the Locate button to specify the location of the dSYM manually. There is also a checkbox here for using Spotlight to find the dSYM; it's possible it got deactivated if Spotlight was borked at some point but is now fixed.
It seems that you cannot do this while Instruments is actually instrumenting, but it does seem to keep the setting for the next time you hit Record. It does not, however, seem to remember the setting after you close Instruments.
Did you ensure you are signing the app with a development profile (as opposed to a distribution profile)?
Be aware that you are usually using release builds with instruments so make sure you didn't choose a distribution profile for your release configuration...
I've seen Instruments 4.2 fail to symbolicate several times with the correct dSYM file.
After saving and quit/restart Instruments, it will then symbolicate.
(Sometimes I'll capture a small sample and make sure it works before collecting large samples.)
Aside from xcode's tools, you can use atos: https://stackoverflow.com/a/4954949/312725
Be sure to take slide into account as well: https://stackoverflow.com/a/13576028/312725
(I'm adding this information to several related questions that are related to that, but aren't exactly duplicate questions. This is copy-pasted, it's a honest attempt to help someone who googled that question rather then spam.)

Resources