The biggest announcement from WWDC so far (In my opinion) and can’t find any discussion of it here:
So the obvious question is, will Unity support this and if so, when? In light of the ballooning file sizes from the IL2CPP builds, this seems pretty important!
From the description (“You continue to develop and upload full versions of your app to iTunes Connect. The App Store will create and deliver different variants based on the devices your app supports”) it looks like you don’t need to do anything - Apple will probably just split the architectures up within the IPA executable so they don’t take up as much memory.
I’ve been reading up on this and App Thinning isn’t the only technology Apple released to reduce app sizes. Brilliant.
App Thinning is the highest profile. From what I have read, it seems that 32-bit / 64-bit / Metal API / etc. will be omitted automatically. But there will also be the opportunity to put art assets in an Asset Catalog to tag them for individual devices. So there is some work to do.
On-Demand Resources is another new feature. It seems the basic idea is that some content can be downloaded only when needed, and removed again when it won’t be used again. This is useful, but will use data on the player end, and require connectivity. Something to think about before use.
Bitcode is the 3rd new feature I have heard of. This is optional, but will be the default. The developer uploads an intermediate representation of their app instead of a pre-compiled binary. This is required for App Thinning to work, but also allows Apple to update their compilers, improving the binary without the developer having to resubmit.
I too was excited to hear about this stuff, and was surprised no one was talking about it.
I was also hoping that it would all “just work”, so I tested it out yesterday. I tested with Unity 4.6.5f1 and I had to download the Xcode 7 beta. I think I had everything set right (enable bitcode set to yes), and I built and uploaded a build to test flight. The test flight info says my build actually went up by 8mb since the last 64bit build that I made with Xcode 6.3.2 (129mb vs 121mb). That seems to be the wrong direction…
FYI, my 32bit build was around 60mb.
I’m going to try again with the latest Unity 4.6.6 tonight and see if anything is different.
Well I don’t think you should worry at this point, perviously I worry about Unity did’t support metal and Unity just do it very fast, so I think Unity will also support iOS 9 new features too.
But if Unity did’t make it, I think you can also use those features by packaging your assets into few AssetBundle, and write some Swift(or Objective-C) code to interact with Unity, by this way you may able to manage your AssetBundles as normal files in Xcode. (Well I didn’t actually try this, just think it may works.)
I completely agree that this is one of the more interesting features announced at WWDC (along with Apple dropping OpenGL and most likely Vulkan). I agree that this is really interesting for end-users to reduce the annoying download size of modern games for the mobile market.
I think that this is a great opportunity for Unity to rethink their quality settings and resource management in a way that better aligns with Apple’s resource manifesting. Android, already has the concept of downloading a version that fits a certain hardware manifest requirements and thus the work could be used on multiple platforms. Also, I think managing quality settings could just be a lot better to work with in general.
For example, I watched the What’s New in Metal, Part 1 and they actually give an excellent breakdown where this type of resourcing could be useful. (Go to WWDC15 - Videos - Apple Developer and skip to 29:20 for the part I’m talking about) Imagine if Unity would automatically package various versions of your assets to fit certain quality criteria. Let’s say that you want to support ASTC on devices that support them, but you fallback on PVRTC on earlier versions of the hardware. With App Thinning you could make a large build that included both textures but then send Apple the JSON to manage the resources for our users.
For example, imagine in Unity for example having a quality settings breakdown that not only uses global rendering settings like it currently does but also the ability to set specific devices (or general hardware limits) targets. Then let’s say you have a texture you want to use. You import an uncompressed texture resource. When you select this texture asset, the inspector would allow you specify different texture compressions for each of these quality settings per platform and per quality target. This resource would automatically be built for each quality type that you specify at build time rather than import time. You would then reference this texture as the reference in the editor linkings and would provide a single point of truth for changes to this resource. For meshes and other resources, this gets a little more complicated. Meshes couldn’t automatically change their quality settings (although having a built-in decimator would be pretty cool) so you would have to create a resource reference asset. This type of asset basically works like the texture importer, but you would link specific assets that you would use in the various quality targets for each platform. Again, in the game, you would use this asset reference asset for putting into prefabs and into scenes, and the build would automatically load the appropriate resource based on the specified quality setting on the reference. Materials references would also be a great way to abstract usage of different shaders on different quality settings.
I think Unity’s current plan of making Asset Bundles is fine, and could be useful for an intermediate path to get to the end goal. However, I don’t want to manually setup the asset bundle(s) myself. I want to manage the assets at the asset level and use these asset references in the editor and let Unity create the necessary asset bundles for specific quality settings on the final executable.
Sorry, that post was kind of stream of consciousness, but I think it would be a great way to manage resources at different quality levels. Maybe for Unity6… but sooner would be awesome. 
Hi moonjump, We’re trying to work out if we actually need bitcode to get the benefits of app thinning. Where did you hear that bitcode is required for app thinning to work? Is it required for app slicing?
It was amongst the details released at WWDC last summer (which is when I posted the information). There should be much more detailed knowledge available now, but I haven’t been keeping up to date on it.