I would like to have an app which simple opens different websites for different languages. So the main purpose of the app is simple to redirect to an web app. My questions:
does Apple allow such apps (in the Appstore of course) ?
how can it be achived to be listed in the different istores (by country, according to the language)
how to I open different websites for different languages?
Thank You!
Apple does allow Apps that just contain UIWebView pointing to a website.
Use NSString *countryCode = [locale objectForKey: NSLocaleCountryCode];
to find the Country code
Using a simple condition, set the URL relavent to the country code.
1) Yes, it is allowed, though discouraged and highly annoying. I immediately uninstall apps that do this.
2) You'll have to setup localization for your app for each language you would like to represent
3) You simply setup a web site, and write it in the language you would like on the site. Localization will save time here, too.
Although this might draw some traffic to your sites, it is not a good business model and you should probably try to make your app do something of benefit for the user. If your app is useful, you will get more than enough traffic to your sites through gentle prodding or in-app announcements of some kind.
Related
I want to add local languages for the description of my app, and so I made a new version just so I could Localize the description. However, I did not change any of my app to be location-dependent (It's just english, and it's a rather simple resistance-color code calculator app without much text, and operates on the basis of color-codedness.) Will my app be rejected for failing to truly "localize", per se? Is this a stringent guideline or is it okay to just change the app store description language?
I don't know if Apple will reject you on that basis or not. But doing something like that could anger your customers, and I wouldn't blame them. I would suggest that you either localize everything, including the content, or localize nothing. Misleading your customers is not the path to long-term success.
Your app should not be rejected. I've done this. My app is mostly numbers which is universal. I've translated descriptions to 6 languages and the app is in the app store just fine.
Don't mislead your users. Your users are your greatest allies or enemies, depending on your attitude. If you don't respect them, they won't like you.
If you want to make a localization, create a support for multilinguality and you can add languages later on. Also, in my opinion your users should be able to choose the language they want to use your app in. As a default you can choose the language of the region. However, it's rude to localize by location and not letting the users to change their language. If you show respect towards your users you will have greater chance of success.
I'm planning to implement some app that performs similar functions as some website does. An app should be able to post, get and view some data. Most viewing data is available only after login. Payments. The webservices are .NET asmx XML services.
So, I'm planning to use UIKit, drag and drop some text fiels. For posting the data, I will do some manual input validation, assemble input into a string, post it to the server. Also, some parsing will be done after getting info form a webserver. Now, I haven't done any website app before, so I'm just curious what are the potencial problems that I might run into.
I guess you are asking about potential technical issues. The ones I faced recently working on an app of this type and workarounds are:
Maintaining your session with the server if you are combining native UI screens together with UIWebView's of your website.
XML Parsing can be hairy at times, so JSON is the best option depending on your preference. The other solution is to output XML in the PLIST format which is easier to code against. On the server side PHP has some PLIST generating libraries. Am not aware of what is available on .NET.
On the iOS side the ASIHTTP library helps make it easier to post to websites, particularly when you are using binaries etc.
Depending on your use case you may also consider a pure web based UI version which resides inside a UI webview. If you are planning on going this route JQueryMobile is a pretty good solution for rendering iOS like UIs. This saves you quite a lot of effort on the communicating with the webservice and parsing etc.
Thats all I can think of for now.
Biggest problem might be getting it approved by Apple if they think it should be just a website and not an app. They might cite: "Limited Functionality". see : https://developer.apple.com/appstore/resources/approval/guidelines.html
I can also reccomend www.sudzc.com
Your UI will certainly not be as responsive as a native app.
Your users won't be able to use your app without an Internet connection/flaky connection
You'll have to rebuild all native controllers yourself if you wan't your app to look like a native iPhone app.
You'll have to rely on libraries like PhoneGap to use most of the hardware/non HTML supported functions (like geolocation, camera, etc.)
Etc.
I want to develop a native universal app(i.e for iPhone and iPad) for my orgaization.I want to include some of the essential features of the organiztion website into my native app.For obvious reasons i cant store this huge data into iPhone itself.so data will be fetched from the server but application would be a native app.so are there any APIs available to do this?
I always find it's easier to start using sample code, and lucky for you Apple provides a lot of this. Here is the reference library for all kinds of goodies to learn off of and hack your way through: http://developer.apple.com/iphone/library/navigation/index.html#section=Resource%20Types&topic=Sample%20Code
A few noted ones... (I left out some advanced ones like BonjourWeb Reachability and AdvancedURLConnections but look at those once you gain a little more understanding)
URL Cache: http://developer.apple.com/iphone/library/samplecode/URLCache/Introduction/Intro.html
RSS Feed Parser: http://developer.apple.com/iphone/library/samplecode/SeismicXML/Introduction/Intro.html
MailComposer: http://developer.apple.com/iphone/library/samplecode/MailComposer/Introduction/Intro.html
Also, a couple books you should get to start your journey on iOS (these are two of the best and easy to understand IMO):
http://apress.com/book/view/9781430224594
http://apress.com/book/view/9781430225058
UIWebView will show any web page you point it to.
Maybe do a mixed approach with some stuff built right into the app, and the bigger or frequently changing parts load from the web.
You can use the UIWebView to access your organization's website from inside a native application...
While I agree that you may need to do your research first, the IPhone/Ipad SDK includes a very easy to use XML parser (NSXMLParser). I would suggest you devise a XML web service for retrieving the data from your company's servers and parse it on the ipad/iphone to the presentation you require.
Best of luck, i've found objective-c very rewarding/challenging.
When I implement OAuth in iPhone, I have a dilemma to choose Safari or UIWebView to open the Twitter pages for user authentication?
I write some advantage and disadvantage of both case:
Using UIWebWeb. The disadvantage is users have to enter their credentials in our application. It's maybe risky phishing. The advantage is this approach will not quit our app.
Using Safari for user to authenticate (this approach automatically callbacks to our application) Addvantage: less risky. Disadvantage: have to quit our app
A good reference link about this: http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice
Which approach do you prefer?
Any response is appreciate. Thanks.
The vast, vast majority of users will not understand or care about the distinction. Do whatever makes their lives easier, or--all else being equal--your life easier. And so long as you are trustworthy (you're not phishing or peeking at their credentials, right?), you'll be providing a good experience and not screwing them over. In this case, I'd use the UIWebView.
The guy who did the Pownce iPhone app a couple of years ago sort of publicly debated with himself about this.
His blog doesn't seem to be up anymore, but basically he implemented it the "right" way as far as OAuth is concerned. Instead of entering credentials inside of the app, Safari was launched and they were entered in there, and then a custom iPhone URL was used as the callback to relaunch the Pownce app. Pretty neat, eh?
Some time later, the developer followed up with a comment that a lot of people were downloading the app but not actually using it. His conclusion? That his brilliant OAuth scheme was to blame. Users were confused by Safari launching and being taken out of the app.
To be honest though? I think the fact that the app was for Pownce, a service that nobody used, was to blame.
I have an app in the app store right now that uses the Foursquare API, which supports both Basic HTTP auth and OAuth. I decided to "do the right thing" and use OAuth. The user enters their credentials directly inside of my app. Am I saving their username and password in plain text anywhere? Nope. But could I be? Sure.
It might sound like I'm arguing for both sides here, but what it really comes down to is that it's very unlikely that your users will know or even care about what OAuth is. It's probably just as unlikely that they will even think twice about putting their credentials into your app. OAuth is great (a hell of a lot better than OpenID) but wasn't designed with the iPhone in mind. It's built to work inside of a web browser. I think the Foursquare API docs put it best when talking about their Mobile/Desktop client OAuth scheme (different from what they want you to do for a web app) - "We provide this mechanism under the assumption that if a user has installed your application on their hardware they, trust it enough to pass through their authentication information to foursquare."
I've already implemented this as a drop-in set of classes (open source). Feel free to take a look: http://github.com/bengottlieb/Twitter-OAuth-iPhone
For the best user experience with destop and mobile application, we should use xAuth:
http://docs.google.com/View?id=ddkz8b2q_76d95356mz
As of May 31st, 2017 and onwards, there is no option left. We MUST use Safari, since google now does not support OAuth via UIWebView. Refer this link for more details.
I'm trying to figure out if its possible for programmers to build an itunes client app for iphone or android where the user has the option to browse and listen to the song preview, something similar to this page: itunes link maker
I greatly appreciate any pointers or links in this direction
thanks
I would imagine your main problem is going to be legal rather than technical. The Apple Website's terms of use say:
Except as expressly provided in these Terms of Use, no part of the Site and no Content may be copied, reproduced, republished, uploaded, posted, publicly displayed, encoded, translated, transmitted or distributed in any way (including “mirroring”) to any other computer, server, Web site or other medium for publication or distribution or for any commercial enterprise, without Apple’s express prior written consent.
I'd be surprised if an iTunes Store Browser application passed Apple's approval process since the iPhone already has one and it's even more unlikely that Apple would let you use their content for an Android application.
Try this.
You'll notice that there is a field called "previewUrl". This gives the url to direct to for the preview of the song. It's not hard to play around with the link to generate content for whatever you're looking for. Make sure you've got an affiliate license first..... May as well make money out of any purchases.