I'm working on a watchOS app with a modular large face complication. The Assets.xcassets file in the WatchKit Extension includes a Complication folder with one image set each for Circular, Extra Large, Modular and Utilitarian, but in my case I have multiple possible assets for the Modular type, which I will choose from programmatically (called Bottlefed, Breastfed and Pump). I was able to rename the Modular image set to Bottlefed, and then added the other two image sets to the Complication folder and populated them with images:
But doing this ends up showing the following warning in Xcode:
I can't find any documentation or examples of people using multiple images for assets to show me if I'm doing this the intended way or not.
Note that my approach does actually work, as far as adding multiple assets to the asset catalog and selecting from them programmatically. But the warning in Xcode is irritating, and makes me think I'm not doing this the correct way. Any thoughts?
In the end, turns out the easiest thing to do is to simply not use the Complication folder in the WatchKit Extension's asset catalog. Just putting the assets in the top level of the asset catalog and ignoring the Complication folder still loads the images into the complication, and avoids the Xcode warnings. (Shoutout to the maker of CARROT weather for helping me out with this one!)
Related
I can put files into Assets.xcassets or I can put files into folder references (the blue folders). When would I choose one over the other?
You should probably use asset catalogs as that's what Apple wants you to use going forward (the tools will reflect that) and they bring many advantages:
App thinning
Setting asset properties without code, e.g., rendering mode or slicing
You don't have to remember naming conventions like #2x, ~ipad, -568 etc to get device-specific assets automatically
Asset catalogs will point out missing assets if you tick the right boxes for the versions and devices you support, and they provide a nice overview
You should get used to them as some platforms (e.g., watchOS) require you to use asset catalogs
There are a few caveats:
If you deploy back to iOS 6, some features don't work as expected – asset catalogs still help to organize your assets, but the runtime features won't work as Xcode will just dump plain image files into your bundle.
If you deploy to iOS 7 or later, Xcode will compile all assets into one .car file (that's the whole idea). However, this can be harder to debug because you cannot look into the compiled file, and it also means you cannot simply get a file URL from a single asset. To create a file URL, you always have to load the asset (by its name) and write it to disk first. *
The last point also implies that you cannot use the NSBundle (in Swift 3.0: Bundle) APIs to retrieve URLs or paths to image files. In order to load assets from a bundle other than the main bundle, you rely on Apple to provide an API, which they do since iOS 8.0. If you organize shared code in resource bundles and deploy to iOS 7 or earlier, you shouldn't use asset catalogs. This is probably mostly relevant if you intend to develop a framework.
* E.g., the CoreSpotlight API allows you to set a thumbnailURL, but if your image is within an asset catalog, you must either write it to disk separately yourself, or use the thumbnailData property. If you had a file URL to begin with, you'd never have to load the asset into memory. I'm not sure if Spotlight could access file URLs from within your app bundle. It's just an example.
You should use Assets. Many benefits the folder references can't do
1) Change color of image without any code
2) Support vector, pdf better.
3) Support Slicing image.
4) Manage resource easier for autolayout. If your resources has 1x, 2x, 3x and ipad image size != iphone image size, you can add 6 files into 1 asset item.
You can read more here
http://krakendev.io/blog/4-xcode-asset-catalog-secrets-you-need-to-know
Suppose I have a complete "app framework" I use for different customers. What is different for each is a config file (e.g. where to download new data files), data files and style files (e.g. background image and launch images)
I could of course
Copy code files around to different app folders replacing old ones.
Copy data/config/style files in/out of a single directory.
Use targets (just read up on these, new to xcode) - but does that work well with different asset folders, launch images etc?
Is there a better way? Somehow make a skeleton app / library that each specific customer app then inherits from? How about storyboards etc?
Only thing each customer specific file would change would be all the plist info, ID, launch images, data files etc. The code would be completely unchanged (I expect the skeleton app can handle whatever small nuances each customer will need, but far most is handled by config files. However, should the need arise, it would of course be nice if I could have cusomer specific code and visuals in each customer app, but this is not a requirement from my POV)
From what you're describing using targets is your best bet. So for example you'll have 5 targets in one worksapce, each target is a different app, all are using the same global.framework, each target got her own config.h \ config.m files
What would be the best way to include a lot of images in the bundle? I have an index of (game) items thus about 4000-5000 image files (total 27mb so not that big). Just include the whole map in the bundle or maybe first write a script that converts them to NSData? I could imagine there would be a smart way to do this so the app wouldn't have to look through all images individually to find a single one. Would love to hear your thoughts.
27mb isn't a huge amount to download so the easiest option would be to put them in an asset catalog, as Ryan Heitner mentioned in his comment this will allow App Thinning to take place in iOS 9.
I'm not sure what you mean by this:
I could imagine there would be a smart way to do this so the app wouldn't have to look through all images individually to find a single one
Each image will need to have a unique name (this is true regardless of the number of assets you have) and your code references the images by that name so it won't have to "look through all images individually to find a single one".
Alternatively if you really want to reduce the initial download size you could use On Demand Resources (another upcoming iOS 9 feature) to store them on Apple servers and loaded on demand in your code. Presumably you won't be targeting only iOS 9 though so in this case you would need to host the resources yourself and load them using standard techniques (see here, here, here, or use a library.
You should pack them in a texture atlas.
Then, the texture atlas files should be imported in your bundled via a folder reference (blue folder icon) and not a group (yellow folder icon).
Images imported in bundle in folder reference won't be optimized be Xcode on packaging. So you can make your own file optimization using imageOptim. It can compress a lot more than what Xcode can do on JPEG and PNG images.
I have really large number of images just in Images folder of my project (just #1x and #2x.png files). It's time to support #3x displays and I've decided to move to assets catalog. Are there any tools/scripts to automate this?
Normally you already have an Asset Catalog because of your AppIcon. If not, choose File:New:File ... and then select iOS Resource:Asset Catalog.
The images you want to import should be named properly: image.png, image#2x.png. If you target both devices: image~iphone.png, image#2x~iphone.png, image~ipad.png, image#2x~ipad.png.
Then select Asset Catalog and press +. Choose the folder with the images you want to import.
Like that it´s very simple to import large numbers of pictures and you can have the same folder structure in your Asset Catalog, as you had before.
You can try iMigrate, that I created recently. So it wasn't properly tested and you can use it own risk.
You can make one of your own using Apple Automator. It is an automating script maker tool provided by Apple with the Mac OS. You can find plenty of online tutorials for it if you Google it up. Here's an example. Click here
I have a number of apps (about 16 at the moment and growing) which have pretty much identical code. That is the code that drives them is the same.
There are a few things that change between apps, they are:
A PDF file (inside the bundle)
The icon
The name
4 Storyboard screens
As you can imagine it would be a nightmare to maintain 16 independent projects, my main concerns is that Features/Bug fixes in the main code will have to be applied 16+ times. The other thing is actually building and pushing 16 different binaries to the app store.
At the present time (Jan 2014) I want to know if there is a way to do this easily so that I only have to make a code change in one place and the 16+ other projects are updated and pushed to the store.
I have thought about git, or just having 16 projects and writing a bash script to do it for me but that seems dodgy. What is the most elegant solution to this problem that will reduce my overhead?
p.s. I don't want one app with 16 different icons/pdf due to size reasons
p.s.s. Please don't make as a duplicated, I want to know what solutions are there today, not a link to a slashdot question from 2010 :P
You could create a project for each app (so you won't have to change the project settings, e.g. name, icons, bundle identifier, ...) where you add the different PDF files and setup the storyboard screens.
Then you would create the classes in one project and drag & drop the files to the other project but uncheck the Copy items into destination group's folder option. That way you can change the code in any of the projects and it will be updated in all of them. You still have to build and submit each project on its own.
You can create one Xcode project file, with multiple targets. Each target in the project can have its own plist, icon, PDF and etc. Everything else will be shared and in one place.