iOS provides a lot of frameworks, I am new to iOS but there's one concept I am not sure of:
If I minimise the number of frameworks my app depends on, I assume that is a performance boost, am I correct? or does it not matter?
For example, am I saving on memory footprint, or optimizing performance if I do not iOS frameworks ( like core data or core graphics ) if I really don't need the functionality in them? in my app the code is too simple that I can write it myself without core data ( very basic functionality ) .
I couldn;t find good articles that discuss this concept, do all frameworks released by apple get deployed on the device irrelevant of your project using them or not?
It's generally best not to link to frameworks you're not using. To answer your more specific questions:
do all frameworks released by apple get deployed on the device irrelevant of your project using them or not?
Essentially yes -- they're provided as part of iOS, so they're already loaded onto the device (and always present).
If I minimise the number of frameworks my app depends on, I assume that is a performance boost, am I correct?
Perhaps -- the linker/loader won't have to load the frameworks into memory and link your app to them, but the performance cost for doing so is so minuscule that avoiding linking/loading a framework isn't a good reason to not use it if you otherwise would find it to be useful.
am I saving on memory footprint
Maybe. When you load a shared library, the contents of the library get loaded into your app's memory space, so it will increase the memory footprint. However, if the library is already loaded by another app (or by the OS), it'll be shared amongst all apps using it.
Even so, a possibly increased memory footprint is a bad reason to avoid using a framework you might otherwise find helpful.
Related
At first, I will describe my use-case on why I need to add the framework at runtime on iOS.
Let's say I have an app on iOS device. The app requires some 3rd party frameworks to add some external features to it. Now, the features are many. So, the required number of frameworks will be many too. An user may not need lots of features. Just a small set of features. Plus, lots of framework will require a lot of space. The application will be huge in size.
For an example, an user needs only 1 feature. The application provides 100. So, all the other frameworks will definitely be unnecessary.
So, the solution would be to download the frameworks and the necessary files on demand from an online repository, link them on runtime and use them. This would mean the application size would be very small and not bulky with unnecessary stuff.
But does iOS provide that? I have to add an external framework and the necessary files that is not on the app use them on runtime.
Is this possible? Can anyone provide me with some resources on how I can do that?
I have seen some resources on SO and some other sites. The results are not so helpful.
"But does iOS provide that?" - no
"Is this possible?" - partially
"Can anyone provide me with some resources on how I can do that" - unfortunately no
More details: That is certainly not possible out of the box. And it will be firstly a pain in the ass to do achieve what you are trying and (far more important) secondly it will probably not be allowed by Apple. You are not allowed to load new "program code" into the app at runtime. For the simple reason that Apple cannot review what you are about to load. And it would a huge security risk for your users if your backend gets compromised.
What you can do is load resources like images, videos etc. on demand.
You might even be able to come up with some scripting behavior of your app. The server could theoretically deliver code to your app and then your app interprets that code. But that code would not be Swift but some other language that you have to define first. You see where this is going? That is possible while not really doable. And still it might get you rejected anyway.
In particular if you are talking about actual frameworks that include actual binary code is is not possible.
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.
Adding issues to the NKLibrary via addIssueWithName:date: at least allows for downloading issue assets in the background.
But I do not see any other advantage. Why can't the app manage its issues by itself?
What is the benefit of marking an issue as being currently read via NKLibrary currentlyReadingIssue?
The reason why you might want to do this is that Newsstand-Kit also manages the storage of your NKIssues. This means that as free memory on the device gets smaller, Newsstand will automatically start purging your old issues. Quoting from the documentation regarding thecurrentlyReadingIssue:
When you ascertain what issue the user is currently reading, you should set this property to the corresponding NKIssue instance. Newsstand Kit takes this setting into consideration when it purges back issues because of low levels of available flash storage.
So to answer your question, you don't need to use newsstand at all. Just like all of the iOS frameworks you are welcome to roll your own implementation to almost anything on iOS. Newsstand is really just a framework that removes most of the boilerplate you will need to implement an "issue" type framework thats most common in newspapers or magazines.
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! :)
It's a great thing that it's possible to compile an SWF into iOS native app. I think AIR is now the best option to write e.g. small games or interactive books. Of cause AIR app will be slowler than the same app written on e.g. objective C. The question is how slower AIR app will be. Can simple AIR apps be launched e.g. on iPhone 3G or iPAd 1?
And another question is, can arbitrary flash app be compiled into iOS native app?
Will be grateful for any thoughts!!!!!
Performance of AIR vs. Objective C:
For pure script execution, AIR apps perform rather slower than native, including on iOS. However, in virtually all cases the limiting factor of your app's performance will be rendering, not script, so it depends entirely on what you do visually in your content. This is why Crooksy suggested you look at Starling. Without Starling (or similar libraries that make use of the GPU), it's pretty challenging to get decent performance out of an iPad1. It can be done, but it takes expertise and incurs extra work. It will be much better to start with the huge performance boost of using Starling or similar.
Can arbitrary flash app be compiled into iOS native app?
As long as it's made with AS3, then it should compile. For whether it works, two main caveats come to mind: First, a handful of APIs don't work on mobile devices. (I think printing is one example.) Second, if you read in any SWFs at runtime, all actionscript inside them will be ignored. (Not for technical reasons, it's an Apple requirement.) So if your content is split into a bunch of SWFs you'll need to bundle them together at packaging time, and if you absolutely depend on reading in SWFs with script from the network at runtime, you're going to hit a wall.
Hope that helps!
Check out the new Starling frame work.
http://gamua.com/
Here's the start of a nice tutorial series (episodes 1 and 2)
http://www.hsharma.com/tutorials/
Lee Brimelow also has a few tutorials
http://www.gotoandlearn.com/
Regarding converting Flash apps into iOS compatible apps, yes that is possible but it depends on what the app actually does as to whether any modifications will be needed before it will perform correctly on a device.