I've developed an iOS 5 application with a rather large cache stored in /Library/Caches. I've noticed that running the app on an actual ipad is getting very slow. As in 5 minutes or so just to launch the application. Without Xcode, the application launches quickly. There seems to be a correlation between the size of the cache and the amount of time it takes to run the application, as the application starts quickly with a minimal cache.
I'm assuming that Xcode is making a backup or something silly like this. Has anyone else experienced this, and if so is there a workaround?
EDIT: (for clarity)
The structure of /Library/Caches/ is:
./big_ass_image1.png
./big_ass_image2.png
...
./big_ass_imageN.png
I simply read them in with coregraphics at a later time. The issue is the speed at which Xcode actually runs my app on the ipad. It's upwards of 4 minutes, which makes on device development very difficult. I would use the simulator, but it's precisely these big data sets that need to be tested on device.
EDIT: (how the files get there)
The files get into the cache via downloading. And sadly, there's no way to limit the cache size (at least not at the 2 gigabyte level).
Related
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/
My SpriteKit playground book averaged 15 FPS on my MacBook Pro.
Do playgrounds run slower than iOS device simulations? If I run the same playground book on my iPad Pro, will the FPS limitation be similar? Will other apps opened on my computer limit the speed of playgrounds?
EDIT:
Moving code such as subclasses and extensions to auxiliary code in the "Sources" folder of the playground book allow the simulation to run quicker because the code only compiles once.
On the Mac, Xcode's "Playgrounds" are super useful for quick experiments but, due to their nature, terribly slow for "real" tasks.
If your code is more than a few pages long, and/or involves working with the UI, as you do with SpriteKit, the Playground may become really slow, sometimes even unresponsive.
"Playgrounds" are part of Xcode and run on top of the iOS simulator - that's how they display graphics and UI in the "Assitant Editor". The iOS simulator is not really known to be fast either.
On the other hand, "Swift Playgrounds" on iOS is a completely different app, even if it shares a lot with its Mac cousin.
Most importantly, it runs in iOS on the real device, with the real hardware processing, not emulation, which makes it ideal to use for SpriteKit, as Apple themselves often shows in their demos.
I would therefore say that your code should indeed run faster/better/properly on the iPad version.
Even if of course, I can't really know, since I don't know your code - you will probably be the one telling us later if using the iPad version made a difference.
I am developing an app which itself is small (~20m) and builds fast on the simulator, but comes with a large database (~800m) and takes a long time to build on a device. It seems the majority of time is spent on copying(verifying) files in the database which never change. Is there a way to reduce/skip this step and accelerate the build?
Maybe while testing you could put the database in the Documents folder and copy it through iTunes or drop the files in the right folder on the simulator.
I think that way Xcode won't need to copy the file to the device, but of course it makes for a slightly more complex setup on the first run.
I'm developing a reasonably simple app using Xamarin iOS and the smallest size I've gotten for the .app file is 13.5 MB.
I've performed all the recommended optimizations - no debug symbols, LVVM code generation, thumb-2, link all assemblies, single architecture only (ARMV7).
The first question is, does my 13.5 MB sound like something to be expected from Xamarin iOS, or am I likely doing something wrong?
The second question is, how much extra size overhead does Xamarin iOS add to an equivalent native implementation (roughly)?
The third question is, roughly how small can a Hello World app get compiled down to using Xamarin iOS?
The fourth question is, roughly how small can a native Hello World app get compiled down to?
The .dSYM is a directory that includes debugging symbols. This is not something you're shipping as part of your application (to your end users). Note that this is produced even in non-debugging builds since it allows you to symbolicate crash reports (that comes from end users running the release binary).
For the real application size you need to look at the .app directory.
You can learn quite a few tricks to reduce your application size (and build time) by watching this year Evolve video Advanced iOS Build mechanics. That will also answer the other questions you had.
Xamarin apps are a bit larger in release mode, as one would expect. As an example, looking at my binaries from two shipping apps, the binary + dlls are around 12m and 18m (I think I need to look into why the 18m one is so much bigger...). I would guess if I had done these in objective-c they would have been around half that size, from past experience building native apps.
If you're running debug hardware builds, they are enormous. the 12m example above jumps up to 96M (?!) for binary + dlls. Before I checked this, I had in my head that they doubled in size to deal with software debugger, but I guess there's a whole lot of other crap going in that I wasn't aware of.
I've got an iOS app that links to 15 Apple frameworks (including the ~3 basic ones every app uses). I've noticed that my app's load time, and time restoring from the background, is pretty high, though the executable is only 600kb. Could all these frameworks be the cause of the load time issue? And is it possible to, say, lazily-load frameworks as needed?
Yes dynamically linked frameworks do affect load time, you can see this in instruments using the time profiler. You should see dyload running as your app launches and it will take time to load in each framework.
Even worse if have static code in something like +initialize this will run at load time too, further slowing your app.