I want to reduce the size of the app to its minimum level. So what all resources i can load from remote after installation? I know I can download images from remote. But can I download libraries or pods from remote after installation? I know we need those files to generate ipa files. Is there any way to setup app with minimum required code, and "load" rest of the code from remote, and is it even possible?
On a different note, I think there should be a framework which checks for existing libraries (like AF Networking) on device, and if it is not there, then downloads it, and all the apps which need it use it. This will help reduce the size of apps considerably.
For assets (images, movies, sounds, etc...) absolutely.
For executable code (libraries, frameworks and pods) absolutely not.
That would directly contradict one of the rules that Apple has in place on apps on the App Store.
Any executable code has to be bundled and submitted to the App Store for approval.
Apple's iOS developer guidelines state:
3.3.2 — An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).
Related
The task is to use different API URLs inside the Flutter application for the app installed through the Testflight and for the app installed through the App Store.
Libraries like: store_checker and detect_testflight
do not give 100% results, and I cannot be sure that they will not stop correctly detecting the installation source after the next update.
I also cannot rely on the kReleaseMode constant, since there is no way to create a build that compiled in debug mode and uploads it on a Testflight. This can only be done in release mode.
Using custom configuration files and setting up the .gitattributes file also seems like a perversion, and is not suitable because, besides the local repositories of many developers, bitbucket is used, in which I cannot add my merge driver. Also, there is no guarantee that other developers will use this driver.
Tell me a simple and concise way to implement this? Didn't Apple come up with the idea that developers would need to use different settings for builds in Testflight and in App Store?
we have a ios app that provides the platform for many similar games. When you install this app. This app already contains binaries of x number of games.
Now we are having size issue. So just wanted to know is it possible to create a ios app that can get installed and after that as per user selection can download the games binaries separately and then run. Like a app that can download games as plugins or extensions.
I work on game side part so i dont know anything about ios apps. but so far my understanding is -> when you create the ios executable then while compiling you should have all the code present (app + all the games it will run).
It is not possible to download a native executable and run it -- that is not a capability provided by app extensions.
One loophole you might consider: it is perfectly permissible to download and run javascript, or anything else that runs in a UIWebView or WKWebView, which are both sandboxed from your iOS App's process, and have access to OpenGLES 2.0 in the form of WebGL. There are also apps which have been accepted in the App Store which can run code in interpreted languages like Python.
I am interested in developing an app for BlackBerry devices, and was wondering if they support the concept of demo or beta releases for their app developers? By this, I mean the ability to deploy a beta or demo version of my app to a limited/restricted audience, such as business partners, customers, external beta testers, etc. Nothing in their Testing and Deployment documentation indicates either way. Thanks in advance!
There isn't a built in beta process in App World for BlackBerry 10, but you can share the debug version of your app with your beta participants. When you create a debug token, you specify which PINs you want it to be valid for. The debug token will only install on a device with one of those PINs, and your app will only install on a device with your debug token on it. The token will only be valid for 30 days. You would have to deploy it with the command line tools and not App World.
This link on the BlackBerry Developer blog explains how to do it: http://devblog.blackberry.com/2012/04/debug-token/
It's for PlayBook, but the same process applies for BlackBerry 10 as well.
I actually don't know if RIM themselves have anything formal, but since I've always released BlackBerry apps on more than just the official App World store, I've used a beta testing system that is independent of RIM. Luckily, the legacy BlackBerry Java platform gives you the freedom to do this, free of charge. (Note that this answer is not about the upcoming BB10 platform!)
Over-the-Air (OTA) Installation
You can have your beta testers install your beta versions, Over-The-Air (OTA). Unlike iOS, for example, you aren't limited to a certain number of test devices, and you don't have to tell RIM what the unique identifiers of all the test devices are.
So, what I do is just put beta versions of my apps on a webserver, and send links to beta testers that allows them to download them. So, you are in control of who gets access. If you need security to limit the beta version to nobody except the official beta testers, then you are certainly free to add password protected logins to your webserver. That works the same way it would for any other secure web content.
If you do this (OTA), here are a few references:
http://www.blackberryinsight.com/2008/07/08/howto-setup-an-apache-webserver-to-deliver-blackberry-ota-applications/
Blackberry over the air installation
https://stackoverflow.com/a/10307074/119114
There are a couple steps to be aware of:
You normally just upload a .cod file to BlackBerry App World. If you want to deploy an app to your own webserver, you also need the .jad file. A JAD file is basically just a descriptor of the app, that can redirect a BlackBerry browser to the .cod file for installation. Your build process is already probably generating the .jad file for you, in the same output directory where it generates your .cod files.
You may need to configure your webserver to properly setup MIME types for files with a .jad extension. If you use Apache, then this is what you would put in your httpd.conf file:
AddType text/vnd.sun.j2me.app-descriptor jad
you may also need to add a MIME type definition for the .cod type, too
AddType application/vnd.rim.cod .cod
If you don't have access to the web server's httpd.conf file, but can place the JAD and COD in your own user directory, then you can configure the MIME types in a local .htaccess file.
Depending on your web server configuration, there may be a couple more steps necessary. Check the OTA links I provided above.
Desktop Installation
Another option is to simply email your beta versions to beta testers, and have them install on their devices using BlackBerry Desktop Software. I don't do this, but it is another way to accomplish the same thing. For this, you use the .cod file, and also the .alx file, which is also generated by the normal BlackBerry build process.
Note that some of the project properties that get put into the .alx or .jad files are things that you don't need to worry about if you only deploy the .cod file directly to BlackBerry App World. If you use one of the options (ALX for Desktop installation, or JAD for OTA), then I would recommend opening up the .alx or .jad file and just inspecting the values for correctness. They're normal text files, and most of the values should be self-explanatory. I believe all settings can be configured from inside your IDE. If you use the BlackBerry Eclipse plugin, right click on your project, select Properties and look around there.
Here are the official RIM docs on all your installation options
its not possible. When you publish your app in app world, it will be available to all users. So you cant set any special conditions like- available only to some people. Else make it in un published mode. Then only users with sandbox id can access your app.
Check the below link for BB 10 Cascades beta 3 release(Preferrable way of development in BB 10)
https://developer.blackberry.com/cascades/
For BB 10,they are plenty of ways for developing the applications ,check the below link
https://developer.blackberry.com/platforms/
I'm working on an ipad application for enterprise distribution (that will be used only by my company people)
It has many video files, images, pdf's etc. after making the app, the size of the ipa is around 2.2 GB.
I'd like to know whether the app will run effectively on all iPad's or will it be trouble to do so?
Looking forward for some solution where it won't effect the performance of the app
If you stay under 2GB, it should definitely work for all devices, since the maximum limit of an app on the AppStore is 2GB.
Since you you distribute internally, it should theoretically also work with a larger file, like 2.2GB as you mention.
Most iPads should have FAT32 file system (or better) which sets the physical limit to 4GB. However I don't know if there exist iPads with a FAT16 file system, if it does, their limit is 2GB!
However, I would not recommend having such a large app bundle. Instead I would use a small app bundle and let the users download the content from inside the application from a company server.
If you need to have offline support, you could provide bundles or packages for the users to download into their apps, and save them there (preferably smaller than 2 gb each).
There are many good reasons for this:
What if you need to release an update for your app? Do your really want to force your users to download a new 2GB bundle just for an upgrade?
What if you want to add more content? Wouldn't it be better if the users could download this from inside the app?
You can let your users download the content in steps (an app bundle needs to be downloaded completely at once)
Let your users choose what content they need to download
Let your users use the app while content is being downloaded
and more...
I'd recommend pulling what you need from your servers when it's needed, (since I assume most of these files currently reside on your servers anyway), then discarding it when you don't need it.
I wouldn't include anything in the build of your app that can be included at a later time.
Are separate apps able to share the same binary in a form like a DLL? I know its possible to compile static libraries but I wouldn't count these as the same as a DLL (i.e. a dll is one copy of a binary shared by multiple apps, whereas static libraries are separately included by any using app).
Is each app totally separate from each other, are there any IPC or file sharing mechanisms available for differing apps to communicate and share data?
Is it possible for an app to create a new process in addition to a new thread (I guess not)?
You can't share executable files between applications. Apple requires that all apps function standalone. However you can use a UIDocumentInteractionController to get another program to deal with files you don't understand, and a 'quick view' may be available. That's how Mail works, for example.
Programs from the same vendor can share the keychain and, I think, iCloud storage as of iOS 5, but can't share storage on disk. As they can declare supported file types, UIDocumentInteractionController can be used to push temporary access to a file from one app to another. A custom URL scheme can be used in a similar way to pass fragments of data if that helps.
As a general rule, only one user process may be active at once in iOS - e.g. background processing is essentially event based. So you can't create a second process for yourself.
You can do this if you are developing for a jailbroken phone. Not
otherwise.On jailbroken phones, you can create .dylibs or shared libraries that can be
loaded via the DYLD_INSERT_LIBRARIES environment var (much like on
MacOS)
Apps are sandboxed. However, there are some ways of communicating between apps. You can use
(a) customURL scheme (also mentioned by Tommy above)
(if any) associated with an app to launch an app and send some
parameters to the launching app
(b) If you control communicating
apps, then you can use Message ports (CFMessagePortCreateRemote)
(c) If you control communicating apps, you could use Darwin
NOtification center for distributed apps.
Of course the expectation for (b) and (c) is that the
communicating apps are all running. On iOS since there is only one foreground
process, you'd have to have the other as a background app and that's
restricted to certain kinds of apps on the iOS platform.
Basically, no to all of the above, unless you're targeting jailbroken phones and are bypassing Apple's App Store. If you jailbreak, I believe you have similar options to those you have in Mac OS X.