Getting User's Carrier Money iPhone - iphone

I'm making an app and i'm curious: is there any way to know how much money does the user have on his SIM without the need to dial it on the phone app?
For example, in Portugal i have to type *#100# to know how much money i have and how many messages i have left.

I think you can not do it. The SIM access requires the use of AT commands, and this is not included in the official SDK. However, you may develop the app for jailbroken devices. Also I'm not sure that the credit is stored in the SIM.

Related

Is there a way/framework to track the SMS (Number/day) and Call data (Minutes/day) on a normal iPhone (Not Jailbroken)

I am a beginner iOS developer and I am trying to build an app which tracks the users SMS (Number) and Call data (Minutes/day) only but have no clue which framework to use. CoreTelephony is of no use as per my knowledge. Any help would be appreciated!
Call Statistics and SMS Statistics are handled by the cell carrier, but are also recorded by the phone and are visible in the settings application. However, there is no way for your app to access this information (as far as i know). It would be a privacy concern and probably won't ever be available. Im sure there is a way to do it on a jailbroken device, but it sounds like thats not what you want. What exactly does your app do?

iPhone iOS: how to detect when in roaming? (Not for jailbreaked phones)

I'm coding an app with heavy network usage. I've been told to warn users for costs but only when in roaming mode.
I know theres some way to know when the phone is roaming comparing two undocumented files on jailbreaked iphones. But I need to find out how to for non jailbreaked phones.
BTW found nothing at SCNetworkReachability api.
Ty!
There's no way to know if they're roaming using the API. You can find out if they're on Wifi or Cellular, but that's it.
You can get the user's home network country code from CoreTelephony.
There are lists to map MNCC ( mobile network country code) to a real country code.
Next get your location, from CoreLocation, and get an address from that using geolocation.
Compare one to the other, and there you have it.
Not 100% reliable near borders, but good enough for a warning message.

xcode share data between iOS devices

I am building an app that will run on a user's iPhone and iPad. People will enter information on either device. I am looking for methods in which the data can be synchronized between the devices.
Would I have to force people into something like iCloud or Dropbox?
I think It would be a good idea to consider using iCloud as iOS 5 will soon make this the accepted standard and people will expect it.
If you don't want any sort of server-side solution (i.e. iCloud or something you write yourself) then have you thought of bluetooth / wifi - assuming the users will have their devices near to each other then you could sync directly from device to device.
However, I would probably have some sort of server that did the sync and stored the data - you could make this free for a certain amount of data and then charge for anything more than that - hopefully that would recoup the cost of running the server.

Pay for a physical product with in-app purchase

I am a complete novice and have no technical skills and little knowledge concerning iphone app development an in-app / itunes store purchases.
But I have been playing with some ideas for my coffeeshop / lunchbar and was wondering If any experts would like to give me some feedback on my ideas.
As I said I run a coffee and lunch(break) shop and allot of my customers are iphone (and blackberry) users. What also happens alot is that the customers ring to order their coffee and food so that they don't have to wait (and waist their precious lunch time).
I myself am an Iphone user and really like the way it works (most of the time).
So I was wondering I is possible or will it be possible to develop an iphone app for my customers and have them pay for the order "in-app". I get a bill of the order in my mailbox and they just chout their name and thats it !?
Might sound a bit low tech but if apple have someones creditcard details and a mobile ordering display then they could function as a cash register of bank ?
thanks,
Jonathan
You can't do this according to Apple's terms of use:
You must deliver your digital good or service within your app.
Do not use In App Purchase to sell real-world goods and services.
Even if allowed, you'd lose 30% of your revenue to Apple using in-app purchase.
There are point-of-sale apps for iPhone that allow you to swipe credit cards. One of the Twitter founders has a startup called Square that'll be doing this. If you wanted it to be an app that users could install themselves, though, you'd likely be best off doing a custom one and hitting a payment gateway in the backend (Chipotle's app is a good example of this).
The original asker is just asking if this is possible, which it is! If you don't take the term 'in-app purchasing' literally. Just use paypal or some other payment method through the app. Ebay does this and so can you.
As long as you aren't selling something that competes directly with Apple (like Sony's digital book store that got shut down) you should be fine using a payment method other than the built-in functionality called 'in app purchasing'.
You have a good idea on your hands and it should be possible to find a way to take customer's money through the app.
Though you could probably use In-App purchasing for this, you would have some interesting work to do to make it work smoothly. You would probably be better off developing your own shopping cart application that lets your customers order "online" and write a custom iPhone application for them - skipping Apple for the purchase of coffee and donuts...
-t

Pricing model for IPhone paid + free app + desktop app

I finished building an app that allows beaming of photos, contacts and text clips over Wi-Fi
IPhone to IPhone and IPhone to desktop.
I want to decide on the feature set of the lite version of my IPhone app. I also want to come up with a pricing model. So the question is, which of these components should be free, and for which I should be charging for ?
For example, the lite version could have all features except the ability to interact with the desktop version - that is, it would work IPhone to IPhone, but not IPhone to desktop. The paid version would be able to beam to the desktop. In addition, the desktop version would be free, so you could share it with family and friends.
Alternatively, there would be a single free IPhone version and I would charge for the desktop app. The only thing here is that I would have to setup server side code for managing registration codes.
One reason to make your desktop app free and the iPhone app a paid product would be to take advantage of Apple's app store and their payment processing, hosting, etc. While I know 30% seems steep for what Apple provides, it is nice to have that part of the business be handled by someone else. For example, you will never have to deal with credit card processing or have to issue refunds - Apple does all that for you.
I like the mechanism that is more suited to viral distribution and giving people a good taste of all the features, before they are sort of convinced to go for the paid version. The marketing value of an app that can be freely tried out once one user recommends it to another, is invaluable. If someone recommends a product to me and I have to pay for it, then I probably would put off trying it till alter when I have learned more about it. However, if it is free, I can download and try it without feeling like I need to do more research prior. Once I like, and am hooked on it, then I will want locked functionality that I would have to pay to unlock.
I'd stay away from selling, payment processing, and reg code management, if your expertise is in coding - you'd make yourself more money writing more code than writing reg code management utilities...
Good luck.
I'm not sure charging for either is the best idea. If you keep both tools free, you get people trying (and liking) both apps. Viral distribution will ensure a decent user base. Once people use both tools, they're more likely to pay for the next part, which is the connector software.
I like your idea of three parts: a free iPhone app (Let people share photos on their iPhone), free PC app (There are hundreds of photo viewing apps, free... Don't try to charge for them, that way lies pain) and paid connection between 'em.
That way:
You get people using your iPhone app virally (To share with each other's phones & try out the application)
You get people using your PC app virally (Because the cost to try is nearly null)
The connection can be sold through Apple's iStore, so you don't need to do the money handling side
You could even make the connection component a subscription, but as an end user I hate that idea unless I get some additional functionality from it being a subscription (Like free hosting).