I'm not all that familiar with Apple's iPhone development system, but I'm trying to figure out if theres a way for developers who create custom iPhone apps to update their apps on a mass scale. For example, would a company who publishes hundreds of apps have to resubmit every app they've made manually if they find a minor bug that affects all their apps (assuming they have used a template)? Or is it possible to somehow use or build a custom program that can make this process easier, by automatically generating or updating apps? I don't believe Apple has an API or anything, but it just seems like it would be a nightmare for these developers to fix bugs, and thought maybe I was missing something.
Thanks in advance for your help!
Apple provides no way to automate this. In theory you could write a program to simulate a browser to login and upload new binaries for you, but I'm not sure Apple would like that very much, and it would be a lot of work.
In addition, one might argue that if the apps are similar enough to warrant this automation, it should probably be one app instead of many. But that may be an over generalization without knowing your use case.
There's the Application Loader
http://itunesconnect.apple.com/apploader/ApplicationLoader_1.2.dmg
(requires login)
It doesn't do bulk uploads, but it does provide a maybe more accessible interface.
Isn't there that separate application that you can use to talk to iTunesConnect? (Though I still don't think it's possible to do mass updates.)
Related
Is it possible to incorporate one iPhone app into another in order to redistribute it?
We're going to publish few apps owned by other developers and need to create some pre-rolls with our branding and some other similar features. The original developer could build the app for us, but won't provide us with a source code.
Sorry if the question sounds stupid, we haven't very big experience in the field, just need to clarify some things
Thank you!
No you can't. You are only allowed to execute your own app, you can't embed an other app in your bundle.
It is not possible to embed an app into another app, or better, you could do that, but Apple would reject it and anyway you would not be able to launch it on a non jailbroken device.
More to the point of your specific case, if you have only the binaries you could try and modify the resource files (i.e., .nib and .strings files) to modify the UI to some extent. Of course, you would then need to regenerate the signature for the app (and hope that everything works ok).
It's just a thought, but maybe you could include the other developers apps as static libraries. The advantages would be that the other devs wouldn't have to surrender their sources, you wouldn't face any code signing and bundle id related issues and including static libraries is perfectly safe.
The only disadvantage would be that the devs would still need to deliver the content seperately and they need to learn how to build a static library. An entry point for each app / each library to call it would also be needed, maybe even a small interface to allow the container app to learn about the individual apps status, to cancel them etc.
As I said, this is just an idea, there may be issues with that approach that I do fail to see right now. But maybe others can comment on this...
You might want to check out this link to learn a bit about building static objective c libraries.
Check apples Custom URL scheme, it might find useful for you. Just help=> http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
Is there a way to pass data to my app upon install from a link to the appstore. Perhaps through a query string or something of that nature.
I am looking for some way to allow the user to purchase a license and pass that license to the app install as easily as possible.
Any information and limitation information as well would be very much appreciated.
The App Store will not pass any query strings after the installation. There are really not much analytics other than how many people bought your app, and currently no real way to figure out where they came from.
As for the reasoning behind it too, another limitation may be App Store rules in general. It sounds like your licensing issue may be better solved through In App Purchases.
I am in the planning and design stage of an idea.
Think of foursquare or quora as the product, I know they are completely different but the dynamics are similar. Crowd-sourced social applications that require user input and engagement.
Given this, should the "product" be a mobile app, website, or both? Are most ideas successful as websites first, with mobile applications as an afterthought? Is the mobile app just a companion or is it the whole experience?
Most importantly, how can I make this decision prior to development? Is there some sort of litmus test to determine which of the 3 options will work?
Any tips, advice, or guidance is much appreciated.
Creating a great mobile app is hard. Now, do it twice, to support Android and iOS. But wait, are you going to support Blackberry? What about once you get outside the US? What about Windows Phone?
With a native app, you do get some advantages. You in general can create a richer experience, have stronger off-line support (if appropriate), widgets, etc. But that flexibility comes with a cost, a significant one, and one you'll pay over and over again. If you can create a purely web version of your product, you're going to have a much easier time supporting a wider range of handsets out of the gate, and nothing precludes you from building native apps down the road. Start out with the app as your primary access method, and you're really creating a lot of up-front work for yourself. Start with the web as plan A and supplement with apps, unless there is a great reason to do otherwise.
I've made some iphone webapps before, using jQTouch and iUI but now i want to try out making a native Apps for iPhone. As i first step i thought of trying to port one of my webapps using Phonegap. So far it works well, but i'm a little concerned about some things in the Apple Review Guidelines and wanted to see if anyone have prior experience and could answer som questions.
2.5 Apps that use non-public APIs will be rejected
2.6 Apps that read or write data outside its designated container area will be rejected
I'm not really sure what this means. I don't think they concern me but if anyone could give me som more info about it it would be nice.
2.7 Apps that download code in any way or form will be rejected
This one is more tricky. Do they consider HTML code? What my app does is to load content into DIV-tags using jQuery.load()-function, that means much of the work in the app is performed on my server. Will it be "safer" if i generate JSON or XML of the data and process it with JavaScript inside the app instead of loading the formated HTML-code?
2.12 Apps that are not very useful or do not provide any lasting entertainment value may be rejected
This one together with the quote:
If your App looks like it was cobbled together in a few days, or you're trying to get your first practice App into the store to impress your friends, please brace yourself for rejection. We have lots of serious developers who don't want their quality Apps to be surrounded by amateur hour.
Made me wonder what they consider a useful app and what lasting entertainment means. This is my first app and i dont aim for a broad audience, this is mostly a way to get to know the XCode, iPhone-development and the App Store review process before. However, the App will be really useful for me and a bunch of my friends.
2.6 Don't specifically try to access files outside your app's Bundle or Documents directory and you should be fine.
2.7 Somewhere, it explicitly says you can download and use HTML/CSS/Javascript as long as you are running it inside an iOS UIWebView container. But don't try to download, say, Lua source code at runtime and interpret it.
2.12 Don't waste the App store reviewer's time if you are just trying to "get to know" the app development or store distribution process. Read about it instead. Submit something only if you think there are people (not just your Mom) who will really want to download your app and not delete it after trying it out. Maybe at least a dozen to hundred someones. If not, distribute some Ad Hoc deployments to your buddys instead.
This just saves time.
Since I already have a web applciation.
I can just stick it inside a webview.
The question is: Does it turn off many users? How many users will be disgusted that the entire iPhone app is written in WebView?
I think it's pretty safe to say that most iPhone users are expecting apps to use the power of the iPhone, not just be a portal to a mobile website.
Think about facebook mobile compared to iPhone facebook app. If you're an iPhone user, I'm assuming you'd much rather use the app than a mobile version of the site (or mobile version of the site contained in a WebView in a an app).
That being said, depending on your app, if the mobile version of your app is highly usable, it could be okay...
Just my thoughts...
John Gruber on Daring Fireball just wrote about this today.
From a usability perspective, native apps usually feel better. They may also be more responsive and handle large amounts of data more gracefully. I have a few so-called "apps" on my devices which are just glorified Web apps, and they don't necessarily scream quality.
If you've already done your app, then just ship it. But keep your mind open to feedback from your users.
The answer is almost certainly "no". People care far more about the usability and experience of interacting with your application than what API-supplied widget you use to render it.
I read Apple has begun removing apps that are like this. Well technically, they remove apps they think could be easily implemented as a webapp instead. Yours obviously qualifies ;)
Source: http://techcrunch.com/2010/03/07/apple-cookie-cutter-apps/
EDIT: Apple seems to not mind, according to the Human Interface Guidelines:
If you have a webpage or web application, you might choose to use a web view to implement a simple iPhone application that provides a wrapper for it.
Of course, Apple has a tendency to contradict themselves. ;)
Apple human interface guidelines says this isn't even allowed. I forget where it comes from, but somewhere in the guideline it says apps that are only web views are not allowed. I'm about 95% sure I've seen this. Can anyone confirm?