I have two similar iPhone and Android Apps (2 each) in the near future we will be combining/merging the best of these two Apps into one App. The App does have a user login that would need to be combined, but a common data file, so authentication should not be an issue. How do I deploy the combined App via the App Store and Google Market for users of the existing Apps? How can I phase the old out and let users know about the new merged App? I thought we could build the MOTHER App and deploy it as a version release in the App Store and Market, but can I deploy the same App version for two separate Apps? For the sake of an example, think of it as Bank of America merging their Apps with CitiBank under a single brand (CitiMobile is now BofA Mobile)
Thanks in advance your your valuable insight.
Merging two apps into one is actually quite simple in android do to the loosely coupled nature of the system. However, you may also consider remaining two apps that can talk to one another with a central content provider and broadcast intents, effectively using your own API.
If one app is the way to go, I would recommend making the super app and deploying it on the market, and deploy a "version" of the two original apps that informs the user what is going on and then points them to the Android Market for the super app.
The other way to do it is to deploy two copies of the super app one replacing each sub app, but that is way more hassle in the long run.
As far as iPhone goes, I can not speak to that.
Related
We have 13 apps that are exactly the same in source code, one difference is app name.
Currently, whenever we have an update to deploy we have to manually do it to every developer account. Is there a way to combine all apps into one source code and deploy it to each account?
If the deploying to multiple accounts is a must, then you can also considering automating this by using the API which both the platforms, Android and IOS have and there are options like fastlane available which make the process fairly easy
If you can switch to a single developer account, then flavours could be an easy way out
Flutter Flavours is exactly for this purpose. A flavour is analogous to say ice cream, well the base content is same but you would like to have a different flavour always right? The best part is you can do something for both Android as well as IOS
You can read about Flutter Flavours here
I need to create an app for a large company.
Their aim is to distribute this app to all of their customers (who themselves are companies - not individuals) and the end-user will be able to query their relevant information through this app.
The app will receive all of its data through webservices and will require login on every use.
On the one hand a web application might be suitable as all the data is anyway online and also distribution of such an app would be trivial.
On the other hand, they might want features in the long term which use the camera etc. and also the administration of the website (in addition to the existing web services) might be a problem - which means a native app working with web services is the solution.
The next question is the preferred way of distribution for this app if it is a native app.
I know Apple have the Enterprise program (which seems to have changed - I no longer see the reference to >500 employees or 250 device limit).
In my case there is one main company distributing the app to many customers so I don't know whether this program is appropriate.
Any advice would be appreciated.
I once had a similar problem... we ended up with the application in the store and an authentication mechanism inside the application. Most likely, customers would have to provide the user credential they use to authenticate at the web application to the iPhone app as well.
For the decision whether to build a native application or use a web application, I would recommend using a hybrid approach. This way you can start with an application which is based on an UIWebView and extend it with features only available to native applications...
I'm about to begin development of an iPhone app. The app itself is fairly basic, and I want a speedy turnaround time.
I'm a web developer myself, specialising in traditional web technologies such as PHP/MySQL; I have no experience in Objective-C.
My plan was to create a very basic iPhone app that is just a Safari service that passes some basic variables to a URL. That URL is the app built in PHP and housed on my servers, this way I can create the app very quickly without needing to outsource anything.
My question is whether apps of this nature would be accepted into the iTunes store, or would they be out-right rejected? Anyone's experiences or comments are very welcome.
Thanks
It could go either way, but mind bullet 12.3 from the App Store Review Guidelines:
12.3 Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected
In my opinion, a simple UIWebView wrapper around your web site comes close to the definition of a simple web clipping. Your approval may very well hinge on your luck in drawing a sympathetic reviewer.
It really depends upon your application...These kinds of application have been approved in the past but again I am saying that it depends on many factors.
Try to test your app in every possible manner and also keep in mind the memory issues.
Best of luck!!!
Should be fine - its called a web app and there is software out there that will do just this for you.
All you need to do is to make a UIWebView and put your web app into it.
Also look at http://jqtouch.com. That gives you some idea of what you can do web-side. :)
http://www.netbiscuits.com/559
Native Hybrid Apps
Native apps can interface more deeply
with the mobile handset modules and
sensors to create an even richer
mobile user experience. Netbiscuits
provides pre-build native apps
frameworks for all major mobile
operating systems to be easily
customized for the needs of
enterprises.
Get "2in1" by combining the power of
mobile websites and native apps by
wrapping mobile websites into hybrid
apps and list them easily in all major
app stores of providers like Apple,
Nokia, Google or Samsung to open a new
mobile distribution channel. The
benefits of this approach are fast
time to market, minimized development
and maintenance efforts and maximum
mobile cross-platform technology
coverage.
Yes, it will be accepted as long as you stick with HTML, CSS, JS and Obj-C on the client side. You still need to wrap it in an iPhone app. In my experience, the best way to this is to use http://www.phonegap.com/ or a similar framework.
You'll have the option of deploying you app through iTunes or as a regular web app (you users will be able to create a link to your web app right on their springboards)
It SHOULD be accepted, granted you test test test and make it look just like a native application. Also you'll have to make sure that your server is never down, or if the application can't reach it just display an error message. You also have to keep in mind that there are a lot of iPod Touch users, and they don't have access to the internet all the time. Which means that chances are you'll get a BUNCH of 1 star reviews
I am interested in writing apps that connect to the intranet or an extranet. In other words, I would like to make private apps for my clients, but I don't want everybody able to access it and be able to download it. Do you know if there is a way to distribute enterprise apps only to a certain people? Does Android do the same thing?
The iPhone Enterprise Developer Program is targeting exactly this scenario. It allows building and distributing apps outside of the AppStore. It does cost $299 instead of $99, however; and it's available for companies with 500+ employees and Dun&Bradstreet number only. If you are small shop working for big clients, you might want to talk with them enorolling in that program so you can develop the app for them.
Update: As #lifeIsGood commented, it looks like Apple has lifted the 500+ employees requirement. At least it's not mentioned anywhere on the Enterprise Developer Program or the Choose an iOS Developer Program comparison page.
They have also added a Custom B2B Apps distribution mechanism, which seems to target the exact scenario the OP asked about.
The answer is.... sort of. You can create ad hoc distribution, but you are limited to 100 total devices in your list. So, 100 customers. Or, you can sign up for an enterprise license, but to do so your company must have 500 employees (there may be other restrictions there too).
[edit]
One suggestion might be to create your application as SaaS - and charge for the connection/data store
[/edit]
I've been looking into this too. I don't think there's a good way to do this with objective-c, but I do believe this can be done well with HTML5.
I'm reading this book http://building-iphone-apps.labs.oreilly.com/
The iPhone supports the web databases, offline apps, and with the webkit part you get icons so your app can look like a real iphone app and be distributed from a web site.
I don't know much about Android...
For Android, all you do is download the apk file to the phone. Then you go into Settings > Development and allow Non-market installs.
I would like to package multiple app in a single app. So donwloading one app and install that in an iPhone will install 3/4 apps. Something like java midlet suits having multiple Midlets in a single jar file.
Is it possible by using multiple target or bundle, aggregate target etc.?
No. Don't do this for a few reasons:
I think it's a bad idea. [More on this below.]
It cannot be done. Multiple apps cannot be installed as a result of one application being downloaded.
Some apps act like bundles of apps, but what they really are is a bunch of mini-apps built into a larger one. I highly discourage this sort of bundling. There are a lot of apps out there that say, “51 Tools All-In-One, Only $1.99!”, but these are incredibly trashy and are bought by unsuspecting noobs with no taste. Don't contribute to that.
If you want multiple apps that can share data, keychain info etc there are ways to do that but leave them as separate app. It makes for a much cleaner user experience.
That doesn't make any sense on the iPhone.
You should look at In App Purchases instead.