I am running into an issue that I am sure many iOS developers have experienced before, so I am coming here to get some help. I work at a company where the design specs for the iPhone app I am working on are made in Adobe PhotoShop. I get these design specs and am told to "make it happen".
In an effort to follow the design specs as closely as possible, I often use the DigitalColor Meter utility that is included in OS X. It is a powerful and useful tool that has been very helpful. The problem is that it is capable of displaying different RGB scales.
So for example, if I am looking at an image exported from PS and I am using the generic RGB scale, I could look at a gray value and get 234/234/234. That's fine. I put that into my iOS app using UIColor and I get a color that looks right, but when I look at it using the DigitalColor Meter the value is 228/228/228!
How can I get a more consistent workflow? How can I make it so that the value I get from the PNG image from PS and the image that shows up in my simulator and even device are the EXACT same? Is that possible?
Thanks!
I am pretty sure that the different iOS devices out there (iPhones, iPads) have different characteristics in terms of their display color profiles: if you used a different device, you would have got a different result from Digital Color Meter.
In principle, to solve this problem, you should color profile the device display; once you have a color profile of the display, you could use that in Photoshop to get the values that you should specify so that the output on the profile display would match the original color.
To create a color profile, you should use a specific tool (colorimeter) and a specific software (there are many on the market).
In practice, since, as I said, each device has its own characteristics, you would need a profile for each one of them and then use a different set of colors for each device. Pretty unmanageable.
What you need is color management in your app.
There is a good color management library available. It's open source.
Have a look at little CMS :- https://github.com/mm2/Little-CMS
From IOS 9.3, apple has built in colormanagement across the devices.
Related
How can I make these kind of pictures?
(Picture 1)
I know you can just take a screenshot, but it looks different:
Even if I don't take the screenshot with iPhone 12 but instead the iPhone SE, it doesn't look like in Picture 1 (unfortunately the iPhone 10 doesn't work because it doesn't suggest for iOS 14.3).
Does anyone have an idea how I can take such a picture?
As #ivanmoskalev said, you need to edit the image yourself (Xcode does not have this functionality built-in). You can look for mockup frames on the internet, but I prefer this app called Rotato.
It's $50 to remove the watermark. But you also get animations and lots of devices. In my opinion, completely worth it.
The realistic device bezel is added later via image manipulation. There is a number of services and scripts that do it.
I personally prefer using templates from Figma Community, there are quite a lot of them:
https://www.figma.com/community/file/891325178364097650
more device mockups
more App Store screenshot templates
Just don't forget to check licensing – whether the template author allows you to use derived images commercially.
Disclaimer: I didn't check for that in the links I posted above, nor do I recommend any particular template.
I have an iPhone/iPod app that I hired a contractor to make. Now I am asking same contractor to support iPad, and the contractor is quoting a ridiculously high price (the BD guy is). I think they know that since they have developed the app, they have some leverage and want to maximize their profit.
Some questions:
Is adding support for iPad mostly a UI job?
Is any coding needed except detecting device type?
Looking at their images/ folder, I can see that for every graphic, they have already made a "2x" version which is double in size. Could it be that they have already created the necessary artwork, as I have told them from the start that iPad support will likely follow the iPhone version?
If I were to use a different contractor now, as it is likely we will not come to a middle ground since we are so far apart in price, what are the things a different contractor would need to do the port?
In particular, I'm wondering if I need to fight to get the raw Photoshop files which contain the graphics, so they can be recreated for iPad, or will going by the eye be good enough? I personally don't mind if the artwork is slightly different.
This certainly makes me think twice about using contractors in the future.
Well here are some answer from my experience:
Yes mostly it just about changing the look of your app. But people are expecting a different user experience on the iPad, so not all view should be full screen for instance.
No most iPhone code will run fine on the iPad, if you are using stuff like UIImagePickerViewController then you need to change the way it is displayed.
NO the #x2 are for retina device NOT for iPad.
Source code and design would do I for me.
Having the original PSD would be nice, but you can do with out.
Just keep in mind that you just can scale up most applications and expect them to become fully excepted by users.
This really depends on the app but there are some differences for iphone and ipad.
Yes, it is mostly an UI job, and depending on screen content, porting one screen can be trivial (just checking if the autoresize functions do their job right), or though - making one from scratch. If your application has lots of complicated screens, I get why the price may be high.
Also - there are some differences in what controllers are available on each device, mostly the popovers or action sheets - that may require different code for each device.
As for the graphics - the 2x resources are actually for the retina capable devices (4th and 5th gen) - most people use them for the iPad too, but as the screen dimensions are not exactly the same, they get warped slightly. In most cases thats ok, but for really high quality, a separate set of graphics may be required.
Take these as generic answers, the complexity of the actual app may affect these answers quite a bit;
1) If the app isn't using any specific functionality on the iPhone that isn't always available on the iPad (GPS for example, or specific camera resolutions for image processing), then yes, it's mostly a UI job. That doesn't mean it's necessarily quick and easy, you may want to change the layout radically for the iPad (that, of course, is up to you though)
2) Most code except UI possibly related code mentioned above should not need much change. Exceptions if any are mostly related to different hardware on different models and depends on the complexity of the application.
3) 2x images are not for iPad, they're for the retina display on iPhone4 and later.
4) Almost impossible to answer without seeing the code or even the app, sorry. If it's a fairly simple application, everything needed should be contained in the XCode project.
5) Up to you, if you want a quick "fix" you may want to resize the 2x images from retina resolution to iPad resolution in Photoshop and use anti aliasing to make them look ok. Your judgement call though. Just check that your deal with the contractor does not give him all the rights to the artwork or you may get into trouble changing/reusing it.
It is. You'll require separate nibs for iPad UI, if you don't want different UI logic, so it's possible to use same view controllers.
View controllers will require logic branches if UI is different. It's mostly checks for user interface idiom though.
#2x versions are for retina display. They will be useful when iPad 3 with retina hits the shelves. Right now, low-res images will be enough for iPad UI.
Different contractor will require the complete code of your project along with all resources...
...so yes, get all the PSDs as well.
First off, I have well over a decade as a professional software engineer working for many clients both small and blue-chip, with broad experience of a variety languages/devices. With that said:
Please remember that the ipad version will need testing on ipad 1, ipad 2 and in a couple of weeks time on an ipad3. Testing takes time. The new version will also need to be tested again on all iphones too.
Also, you mention that this app is a game. The original code might have been coded in such a way as assuming certain screen resolution, and maybe even have hard-coded values throughout the code relating to screen positions etc. Particularly if the coder was not aware of a future ipad requirement. Also supporting ipad 3 might not be an insignificant task if it has x2 graphics depending upon original code and the game engine used (if there is one).
Some apps will cost the same to create an ipad version as the original iphone app.
If your original agreement didn't include IPR over the source you might have difficulty getting it. Some agencies and contractors default to providing source to clients, others charge extra for provision of the source.
Lastly, the contractor might have originally coded the iphone app at a loss, i.e. they might have quoted you and been paid for 3 days work when they actually spent 10 days on it. In which case they might be assuming the worst for the ipad version too.
There are a lot of questions to ask and be answered before you can say they are "trying to rob".
What will happen if I do the following:
I substitute all non-retina assets with the retina assets
I delete all retina assets in my project ( All the ...#2x.pngs etc.)
Why do I want to do this:
There will be less and less non-retina iPhones in the future (also due to minimal OS requirements etc.)
I get a lighter binary
I don't have so many "quasi-duplicate" files in my project which I have to maintain separately.
Now:
Will the iPhone 3GS scale down the image and display it properly (with a little bit of processing overhead of course)
Will a "retina-enabled" Phone be able to display the image properly even though it does no longer have the #2x suffix in the filename.
In 99% of cases this will work fine. However there are cases where images won't scale correctly (usually depending on the contentMode).
I worked with someone who did this exact thing and never noticed a problem, although I think it is terrible practice.
You will get a lighter binary, but you are asking the older devices (with less memory) to do more work. If you don't want to support these devices then don't, I think this is better than giving users a potentially broken app.
There are better ways to reduce the size of images in your app, reusing them wherever possible, stretching, tiling etc.
3GS and iPhone 4 will both display the image improperly.
The fact is 3GS won't scale down the image. So it won't display the image properly. iPhone 4 will scale the non-#2x image (scale it twice) so it won't display the image properly too.
Nothing will happen if you decide to do this. Older devices will try, but if you allow the device to even run your app, you will have quite a bit of work just to deal with the scaling issues. If you allow older devices to install your app, you will have to be prepared to get approved from Apple on older devices too. If the images don't work right on older devices, you won't get approved. You are also right that there are fewer and fewer retina displayed devices in service.
But... there are still quite a few non-retina devices still in service. Maintaining both is good for your users. Yes it adds a little extra heft to your binary, but with today's speeds on a variety of networks, that isn't the issue like it used to be.
While it is your right to choose which users to support, and there are many developers that share your sentiment, it is still up to you to decide which group of users you ultimately want to support. If you are fine drawing the line with retina displays, so be it.
I could finger-wag at you and tell you that you should support every single user, but I'm sure you've thought of that. If you are fine supporting retina devices only, go for it. If you are prepared to answer questions on why this one device is supported and another isn't, go for it. The good news is, no matter what you decide, you'll be right...eventually. Good luck.
Where do you usually grab graphics for your iPhone apps?
Are any free official repos from Apple or one have to buy everything from thirdparty artists?
For example, does anyone know where I can find close button image like one one on this screenshot? Or it is private image?
365psd.com is one of my favorite places to find some brilliantly beautiful interface elements. They give you the PSD, instead of just the PNG, so that you can scale it or modify it to fit your needs. It's like open source for graphic design.
Apple doesn't really provide any images other than the system tab- and bar-button items. Most developers just end up making their own or getting them from third parties, paid or otherwise. A search for “iPhone UI template” might well turn up something like what you're after, probably for free or on reasonable licensing terms.
If you're looking specifically for a “close”/“delete” button, I made one a while ago, though it looks more like the system one than the one in the image you posted; you're free to use it if you like.
Find icons and icon finder is great resource to find different UI icon and graphics for apps
Following iPad's announcement and its SDK (iPhone SDK 3.2), porting apps to iPad becomes an important issue. What guidelines I should follow in my iPhone apps to ensure I can port it to iPad as seamlessly as possible?
The different resolution is particularly an important issue. While the iPad runs iPhone apps unmodified, it's not really the desirable behavior for a native app. How can we make our iPhone apps resolution-independent so that they can run gracefully on all resolutions like most desktop apps?
If you've been using IB and setting the resize behaviors of elements properly, and also coding frame coordinates all relative to each other you are half-way to having a UI that can potentially scale to a larger screen.
From the screen shots there are new kinds of action-sheets as well, potentially attached to UI elements instead of floating - if you use overlays today they will probably work about the same but you may want to consider changing placement from the center on larger display.
UPDATE:
Now the event is over, and registered developers can download the SDK - although we cannot talk about specific features here just yet, read through ALL of the documents related to the new OS version as there are a number of things aimed at helping you transition to supporting both platforms. Also before you start using custom libraries for things take a look through the API changes to see what new abilities might be supported that are not today.
Generally speaking, what I said above about IB holds true, and also you should start thinking about how your apps today could use more space to present more information at once instead of being split out over multiple screens. Also if you are doing any projects right now that use images, make sure to initially design the images large enough that you can also use them for higher resolution tablet applications.
It is far more reasonable to expect users to input text (and larger amounts of it) than with a non-iPad device.
Nothing, it appears. Although we don't have the SDK quite yet. It will all existing run iPhone app without an issue, albeit at reduced resolution.
It remains to be seen how much of the existing iPhone SDK is shared with the iPad SDK UI wise.
Judging by what has been said, absolutely nothing. You will have to adapt to the new screen size and better hardware all together, if you want to take advantage of the features that the improved device offers. The lack of a 3g module is also something to consider if your app(s) rely on that functionality.