I want to upgrade my existing apps to iOS 5.0 and above.
I want suggestions and detailed guide line for main points.
what changes I should make in my existing code to make it fully
compatible as new iOS coding standards.
For e.g.
Should I change all external frameworks and my custom classes
for making it compatible for ARC?
I should make changes into sqlite database creation.
Should I replace old framework of Twitter & Facebook?
What kind of changes I should do with Graphics?
In-short, Please provide guideline and suggestion that are important for making older app fully compatible with New iOS standards.
Guys thanks for providing your comments & reply for this question.
By Looking at your response, I think you guys are only focusing on the
above given points. I want general suggestions from your experience.
i.e. what things we should change in info.plist, what changes should
be done in graphics. how we can improve app by adding automatic ARC
support etc ...
Main thing is how we can make it compatible for different resolutions
of iPhone / iPad (i.e. for iPhone 5 and other devices).
If possible then please provide graphics changes guidelines with
resolution for new iPhone 5 Device and iPad Mini Device.
Your help / suggestions / Guidelines will be greatly appreciated!
Should I change all external frameworks and my custom classes for making it compatible for ARC?
It depends entirely upon you. ARC is a compile-time feature that is meant to obviate the task of manual memory management. It doesn't eliminate it by any stretch of the imagination, but it is miles safer than anything we as programmers could ever hope to write most of the time. It is possible to mix ARC and non-ARC frameworks and libraries in an application.
I should make changes into sqlite database creation.
iOS has always shipped with libSQLite3, so there is absolutely no work required for you to "upgrade" this aspect of your application. You might consider a move to core data, if only because again, it obviates large portions of interfacing with SQLite.
Should I replace old framework of Twitter & Facebook?
Again, it depends. If you plan on supporting older OSes which do not come with the new iOS social features and frameworks, then I'd leave it as is. The new API is far more limiting than accessing the actual API for each of the given social services, but it is also far easier to implement, especially for things like simple wall posts.
What kind of changes I should do with Graphics?
Graphics files must (optimally) come in 2 flavors with an optional third format for the new iPhone: standard, retina, and stretched retina. While opting into retina-graphics is completely optional, it is recommended that you provide high-resolution assets to provide the best user experience. In regards to the actual graphics library (CoreGraphics), the framework handles the scaling of elements drawn to the screen.
- Should I change all external frameworks and my custom classes for making it compatible for ARC?
If your frameworks are out dated then, YES you need to update it so
its compatible for iOS 5 and above. For ARC, its not necessary. If you
don't wanted to handle memory management then you can.
- Should I replace old framework of Twitter & Facebook?
YES please.
- What kind of changes I should do with Graphics?
You need to change graphics for ratina display. Google about it.
Related
Let's assume I want to develop an isometric 2D mobile-game such as Clash of Clans for example.
My main target would be iOS but of course Android would be nice, too (but not a must-have).
Now I have to decide to either program with Apples XCode (therefore Swift as a language, which I am already pretty familiar with), or develop my game with Unity3D (and therefore C# as a language, which I am also pretty familiar with).
Personally, I don't prefer one over the other.
So much for the set-up.
As I don't have any preferences, I'd like to choose the one that offers the most benefits for my 2.5D game to me.
The questions:
Is there a difference in getting an approval for the App-Store if you program in Swift, or use Unity; C#?
How big is the difference of the published package-size of the app between Unity and XCode?
Does my Unity-written app run as smoothly as my XCode-written app?
I hope you could help me with that.
If I missed some points there, feel free to criticize me and give me your opinions on it.
Greetings
Chriz
Is there a difference in getting an approval for the App-Store if you program in Swift, or use Unity; C#?
No, given this general comparison - there should be nothing here favoring or disallowing one over the other.
How big is the difference of the published package-size of the app between Unity and Xcode?
That is very hard to say. There will be added libraries for Unity inclusion whereas Apple would already have shared libraries apart of the OS - used by every app. Think shared libraries here - only Apple is permitted to do this. Not to be confused with the to be newly released iOS 9 'App Thinning'.
The larger weight will be media/images/bitmaps.
Does my Unity-written app run as smoothly as my XCode-written app?
Since they both end up using OpenGL, the end result should be the same or very similar. Obviously as the OS and device mature - if Unity doesn't leverage it, they could end up giving up performance advantages.
But... the flip side of being so tightly coupled with Swift/iOS/Apple, is you abandon your Android market - and if you are even considering it - I'd suggest Unity based on what you shared if there is a remote possibility you want to deploy to Android, desktops, *TV devices in the future.
I am currently deploying to IOS, but plan to deploy to Android and other platforms down the road.
I need to know whether the system volume is turned off so that I can show a relevant icon on the screen.
Within Unity, is there a way to determine whether the system volume is muted?
I am not aware of Unity functionality that would allow you to do that (because AudioSource is tied to object, not to "application" itself) - but maybe there is some magical utility that allows you to do that. The problem is that even checking in pure iOS is not as easy as checking one property, since system itself does not indicate it, or at least it does not work for later version (iOS7, 8 - and possibly 9)
Anyway, I personally think that you have to resort to system specific implementation for both Android and iOS (and whatever you want to support). For iOS, there are great posts that go to great detail, I suggest you check them:
https://hoishing.wordpress.com/2014/05/08/mute-checking-in-ios7/
Detecting Silent Switch in iOS 7 issue
Hope it helps a little, though I guess I did not bring any good news :)
We are creating an iOS app that does not look like any other app you would find in the app store.
My question is, am I allowed to create custom components such as header bars, tab bars, tables etc. for my app and not get rejected by Apple when publishing the app to the app store?
Months of thought and planning has gone into the UI and flow of the app, so the user experience would be superb, we're just concerned about how apple feels about custom apps/components like these?
Regards
There's nothing inherently wrong with creating an app that's got a completely different look and feel to everything else.
But what I would advise is that you try to use the built-in components as much as possible. In recent versions of iOS Apple have introduced a number of APIs to let you customise their look and feel significantly, and some of the most innovative UIs out there are simple table and collection views that have been hacked to pieces.
This is because Apple's built in components have logged many hundreds of thousands (if not millions) of hours of real-world testing and use, and are thus vastly more stable and field-tested than a totally custom component. Plus, they often have various built in features (such as a scroll view's bounce) that are hard to replicate on your own.
So definitely customise your interface as much as you like, but while you're doing it think about whether you can harness the built-in UIKit classes rather than totally re-inventing the wheel.
More and more custom controls appear for iOS every day. If it is so good as you say, Apple will be happy to accept it. Don't worry.
Also take a look at these cocoacontrols
As said before, Apple will not have a problem with that .. as long as you don't use any private APIs. If you are developing these components on your own, you will have to make sure that these will work in future releases (which is not necessarily a bad point) . This may be a problem with third party components, as they may not be continued (or supported in future releases).
I am a developer working on a robotics application for iOS. I do not intend to submit this app to the app store, nor do I have any wish for suggested methods to be apple approved....
I am trying to get bluetooth working, and I think a good place to start is to try modifying the existing apple frameworks. Is it possible for me to modify the frameworks so that when they are built to my iOS device the frameworks will be modified for the app (but not other apps on the same device)?
As a matter of fact, you can!
Objective-C allows you to "swizzle" methods to override their default behavior, and yet still call the original implementation if you want to. You can do this for any number of Objective-C methods, as many times as you want.
If you wish to override behavior that is present in C functions, you will need a little bit more control over the platform. Jailbreaking allows you to use the full power of Jay Freeman's CydiaSubstrate to hook or swizzle both Objective-C methods and C/C++ functions.
While I don't recommend the use of MethodSwizzle per se, the following URL has a good discussion of swizzling http://cocoadev.com/wiki/MethodSwizzling.
But you should really use CydiaSubstrate's MSHookMessageEx and MSHookFunction instead. Especially since you're not submitting anything to the App Store.
Now regarding Bluetooth, I've done extensive work in this field (I developed Celeste, which is a systemwide tweak providing vanilla Bluetooth OBEX support to system apps on iOS). I suggest you look into using something like BTstack, which provides you with access to the bluetooth module from the HCI to RFCOMM levels, and supports things such as SDP and pairing, which you will probably need. It also has the added benefit of not requiring method swizzling, which some people seem to think is some sort of satanic ritual that should be avoided at all costs.
Aside from categories (which extend the functionality of base classes delivered in those frameworks), I don't believe you can "modify" the existing Apple frameworks per se. A better course of action might be to simply create your own framework (or find somebody else's open source, commercial or simply third party framework) and then build that framework into the app that you install onto the iOS devices you want to work with.
I recently started trying to develop apps using titanium.
When i ran one basic app containing two table views and some static data, it showed me 80 memory leaks and about 15 warnings - i think coming from the frameworks.
As an iOS developer, i'm used to seeing less than 5 memory leaks in complex apps too.
So, I'd like to know whether applications are getting accepted by apple when developed through titanium.
Also, I'd like to know whether,looking at the state of the titanium frameworks,its worth learning it right now.
Thanks in advance!
Your First Question, Yes! they are being accepted by Apple App Store.
And For your second question, its relative to likings of individual. I started mobile application development with titanium, but soon I realized that there is no better way to create an application then to create it natively. I would say if the applications you are developing are not scaled at enterprise level magnitude (means thousands of lines of code), better develop apps natively.
Titanium is increasing support and improving frameworks rapidly, its also reduces lines of code by third! and the best thing about it is, its cross-platform! but to my personal liking i always prefer native development. The power, the iOS gives you, Titanium wont!
One more thing i would like to add, despite all, you should learn it! :)