Use Old SKTextureAtlas or SpriteAtlas - ios

I made a game that makes use of many textureAtlases. I am currently using SpriteAtlases in the assets.xcassets folder which works great until testing devices below iOS 10.
Running on any devices at iOS 9 displays this issue below and it won't load the textures.
-[CUIThemeRendition newImageFromCSIDataSlice:ofBitmap: usingColorspace:] Unsupported pixel format in CSI got 5
Unable to create unsliced image from csi bitmap data.
I couldn't fix this issue (I read that it might be a bug) so my only two options I can think of is to either use the old .atlases in the project bundle or only have my game support iOS 10.0 and newer when using the spriteAtlases. Which is the better option or is there another alternative?

Using the .atlas method is old and inefficient. The XCassets .spriteatlas is, by far, a better usage of memory and will make your project run better.
My recommendation would be to not support iOS 9 and lower. Users still on iOS 9 are such a small minority, you would be screwing your iOS 10 users by using this inefficient method. At this point, most people have upgraded to iOS 10 or newer or bought a new device.
It gets to a point where us developers physically cannot continue to support older iOS versions. In fact, if I remember correctly, Twitter just recently dropped support for iOS 9. I think it would be a good idea to follow suit.

Related

Will an app built with an older version of Swift be able to live indefinitely on app store?

Alright, have a question here -
A while ago I built an app in Swift using pods that, for one reason or another, disappeared one day. Meaning the project was there, but it reverted to a MUCH older version and was inrepairable. It's a great app and I released on the app store, so others are using it and that's great but I am unable to update it. The binary is gone.
My question is - with the updating of the app store and Swift (i.e. Swift 3 now instead of 2) will my app be able to run still on the app store in years to come?
Right now with Swift 3/ios 10 it still runs well. It's good.
But can an app written in an older version of Swift live indefinitely on the app store? Or will it die one day? Hoping its not the former..
Whether an app built with Swift will still be available in the App Store in a few years doesn't depend on the fact it's written in Swift. For a released app, Swift is compiled to binary code and Swift libraries are bundled with app. There are no Swift specific dependencies left.
However, Apple might have other reason to pull your app:
Your app hasn't been updated in a long while.
Your app hasn't been updated for the latest devices (e.g. new screen formats).
Your app was built against an old iOS version that lasted iOS versions are no longer compatible with. (Each iOS version contains compatiblity code to run old apps, e.g. iOS can still emulate the pre-iOS 7 UI.)
Your app crashes on newer devices or iOS versions.
Your app violates App Store rules but it wasn't discovered on the initial submission.
Having said that, if your app doesn't crash or violate rules, it'll likely take a few years until there is a realistic chance for it to be pulled.
even app which are written in objective - c also works fine which is more older then swift, then why your swift app will not work? it will definitely work without any failure!! doesn't matter whether it is swift 2 or swift 3!!!

Will the same iOS SDK have different behaviors using different Xcode versions

At first my first question was: Will I be able to upload the the appStore using an old SDK. Looking at the apple Documentation, and a stack overflow question, I arrived to the conclusion that I can upload my application using an old SDK as long as it's in a reasonable amount of time since the new SDK has been released. I could not find the minimum required SDK for approval though. At that point in my research, I think that I can use an old SDK to submit my application. Am I in the wrong? How long should I expect the current latest Xcode 7 SDK to be supported ?
(I do know we should move to the latest SDK as soon as we can.)
My company is working on several iOS projects, and we are having a big patch soon for one of them (maybe in December). We do not want to introduce new bugs. We understand we must change the SDK, but at this point in time, it would be too much time consuming. Some of us would like to enjoy the latest version of Xcode for some native projects, which brings me to my second question. Right now if we have a bug free application using Xcode X (7), can we expect the same bug free application using Xcode X+1 (8) with the same SDK. Is this safe or would we take a risk?

iOS8 extensions - what happens on iOS 5/6/7?

I have an application that was developed to support older versions of iOS as well, but I recently started on working on a Today extension in iOS8. Now my question is, what will happen to my app in the store? Will it ignore it and make it iOS8 exclusive? If not, I wonder what happens when a user runs it under iOS 7 for instance?
I have found absolutely no answer to this, has anyone been luckier than me on his research?
Thanks in advance,
Laszlo
Your extension functionality will not be available for lower versions(iOS7 and lower), However the app still run without any problem in lower versions.It has been explained in WWDC-14 session 217 Creating Extensions for iOS and OS X, Part 2.

Updating app for iOS 8

I have an application whose minimum version has been set to iOS 7.0. This application also uses NSUserDefaults dictionary. This application is using UIAlertView and UIActionSheet extensively (not sure how much Apple non-disclosure covers). Now, with iOS 8.0, these two views have been deprecated and have been replaced by controller UIAlertController. Now, there are two ways that I can see which can help me in updating the app for iOS 8.
Raise the minimum version to iOS 8.0 for the update. This way, the users running iOS 7.0 won't be able to see the update. However, it leads to the following situation :-
However, there is one problematic case, and that comes from upgrades
performed from within iTunes or on a device with a higher version
number that is then synced to iTunes. When the user syncs the older
device with iTunes, iTunes will actually delete the application from
the device because it cannot run the new version currently within
iTunes. I had a couple of users with original iPod touches report this
when I upgraded one of my applications to only support 4.0.
The above comment is present under the accepted answer at the following url :-
Raising minimum iOS Deployment Target Version for App Update
Since, the application is using NSUserDefaults dictionary, the relevant entries in the dictionary would get erased when the application is deleted.
The other option is for me to detect in the code which version is being used and code accordingly using if-else statements. This would enable me to keep the iOS 7.0 as the minimum version and might also help me in deploying the update for iOS 8.0. However, this seems like a lot of work which can potentially lead to bugs.
So, I was wondering which option is better between the above 2 ways ? (This application would only be using Objective-C for now due to some constraints).
The best thing to do from the user's perspective is probably to code using UIAlertView and UIActionSheet even though they're deprecated. Keep your iOS 7 target the same as it's been. Xcode shouldn't give you warnings since you're using the older version as your base target. You won't need to change anything about your code and it should still work well enough.
Once you're ready to switch (perhaps when iOS 9 comes out), I would switch your base target to iOS 8 and update your code to use UIAlertController everywhere. To me, it doesn't make sense to spend time trying to support two different versions if it's just an API deprecation that still allows your code to work how you've written it for years. Saves resources and energy to just update it later.
But it's really up to you and how much you want to support iOS 7. I think it doesn't make sense to drop support until the next version comes out. I always try to support the current and last versions so there are no annoyed customers, but it depends on your own needs.
If you have analytics integrated, check out percentage of iOS 8 adoption once it's been released for the public. If not, it's a great opportunity to add it to find out how up to date your customers are!

ios 5 and ios6 compatibility features -xcode

I want to create a map based app but apple will no longer user google maps in ios 6.I dont want to upgrade to the developer beta yet as I am waiting for the final release. But I also want to get started as soon as possible. If I start my project now will it change or the code will differ when the ios 6 is available? In other words if I make a successful built in ios 5 will it be unsuccessful when i upgrade to ios6? Will I have to rewrite the entire thing or everything will be compatible resulting to an also successful built? thank you in advance..
Your code will work fine.
Almost nothing changes with iOS 6 and MKMapKit in terms of code.
The only thing which works different in iOS 6 is the way you call the native Map App from inside you app. (if you are using this functionality)
You don't need to wait to use beta versions of XCode, you place them in different locations on your hard drive and leave the current XCode in place.
Then you can test in the iOS 6 simulator just to make sure it works as well as on iOS 5.

Resources