I'm quite new at iOS app development.
I'm starting to work on an app that should in somehow be able to count the missing calls that the iPhone has registered since the app is running.
I've read that in no way Apple is going to let me intercept incoming calls, answer them, reject them, or "whatever" them, but I wonder if we are allowed to count them.
I've found some people that say it can be done (well, I knew it is possible, cause LockInfo does, for instance), but I don't know if it's attached to jailbroken iPhones only.
Anyway, as far as I have seen, it must be done with some methods related to kCTCallStatusChangeNotification from CoreTelephony.h if I'm right (as seen in http://blogs.oreilly.com/digitalmedia/2008/02/when-it-comes-to-the.html), but I coudln't find much more info about it.
Hello and welcome to iPhone Development! :) As you have already pointed out, you can be informed through a notification if a call is happening. Great! But here comes the dark side of iPhone Development:
That's the end of the road. 95% of the "Phone Functionality" of the iPhone is private API and you don't technically have access to it.
Of course, you could header-dump the private frameworks and use them anyway, but that will get your app instantly rejected from the AppStore, which wouldn't be fun for anyone.
LockInfo is an extension for jailbroken devices - those guys are known for not caring too much about Apple nor Private APIs ;) Also, as you may have seen, LockInfo isn't on the AppStore because it would've never made it that far.
So Apple, why is there CoreTelephony?
Well, it's there for some very specific reasons. I personally use it to obtain the carrier name of the device for certain country specific restrictions in my application. The notification you talked about, along with others, tend to be used by developers to prepare your app for going into an inactive state (when the call comes in, your app is put in the background), so its used to pause tasks etc... CoreTelephony has never been intended for any deep level access to the telephone system of the iPhone.
So sorry, you can't obtain the information you're looking for using public APIs.
Related
Assuming you created an app that users have downloaded that is just awful and you neither want to fix it nor have anyone continue to use it so that it won't tarnish your brand, is there a way to end its life on user's iOS devices?
Curious if there is some store setting to force it to work with earlier versions of iOS and invalidates the current app, or code that would force an update that says the app is no longer available.
As many have confirmed, there is no way to remove an application from someone's device. For these cases though, many companies have servers that the application sends a request to on launch, that returns either a need to update the app, a message, or to tell the user the app has been discontinued and that the app cannot be used anymore, stopping them from using the app from there on.
The last use case might be useful to you, but of course this is a proactive solution, not a reactive one.
Since IOS 13 came to live old 3 party APIs stopped working, In my app i needed to fix few because of that so i needed to fit it to IOS 13.
Since then Apple keeps rejecting my app because of Bluetooth user notification is not correct.
I just don't know what to write there, It is so annoying. I have to add it because of AdMobs and there is nowhere to say what to write over there.
I don't user BT in my app, it is just the AdMobs beacons that needs it probably.
I've tried:
and
And i will probably will have the same issue with the calendar message also.
When i try to remove it they demand it and then not approving it.... I understand maybe the first one but what wrong with the the second one? why is that no clear enough for them?
10x
see apple docs below: https://developer.apple.com/design/human-interface-guidelines/ios/app-architecture/requesting-permission/
Explain why your app needs the information. Provide custom text (known
as a purpose string or usage description string) for display in the
system's permission request alert, and include an example. Keep the
text short and specific, use sentence case, and be polite so people
don't feel pressured. There’s no need to include your app name—the
system already identifies your app. For developer guidance, see
Protecting the User's Privacy.
you're not explaining exactly why you need access to bluetooth. you must be specific. saying, "XYZ app needs access to bluetooth to interact with beacons to serve you location based advertisements"
something like that should do. no cutting corners, no trying to put it off on Google, just say it like it is and you'll likely pass through app approval without a problem.
I've been developing iOS apps for enterprise use for several years now. It was an adjustment from having spent many (!) years developing desktop apps. One of the first things I learned very early on was that it is frowned upon for an app to kill itself. The posters in the Apple dev forum were downright hostile about it, which is a reason I never go there anymore.
Now I have an app that has very critical functions, and it requires that the user accept the terms and conditions before using the app, and that the app will not function if the terms have not been accepted. The choice is there to accept or to decline, but it seems like the best thing to do when the user actively declines is to kill the app entirely.
My question is, under those circumstances, would there be anything wrong with that? Will I be damned to developers hell for eternity?
You can change the interaction here.
Instead of accept (and use the app) or decline (and never be able to use the app) change it to accept (and use the app) or nothing.
If the user does not accept then they cannot use the app. They do not have to decline anything. Absence of acceptance is all you need.
If they don't accept then don't do anything. They can always come back later and accept and start using the app.
Why kill an app on a declying? I would rather just leave a user at the same screen with no actions before he puts acceptance checkbox, disabling all buttons
If you make the app kill itself, Apple won't let you post it on the App Store.
You should adjust your User Experience to the case of the user declining the terms and conditions.
For example, show a screen saying that the app can't be used unless terms are accepted, with a button saying "Take me back" that takes the user back to the terms screen.
Let me first begin by explaining my goal for this app. I am looking for ideas on the best way to accomplish my goal (or at least close to my goal). This app is completely internal and thus does not need to comply with any apple guidelines (aka, can use private api's).
Our company has ~20 iOS devices. These devices are used by multiple people throughout the organization. Often times we are looking for a specific device and need to be able to track it down. So I am looking for a way to track who has what device.
My initial thought was to make an app that allows the user to pick their name from the list and then have a server that keeps track of who has what device. This worked well for a while, but now people have decided its too much work and have stopped using it. Users can just not open the app or press the home button to exit it. So now I'm looking for alternatives.
Here are some ideas that didn't work:
Custom Lock Screen - (Requires jailbroken devices so not an option)
"Lock To App" from Apple Configurator - (No way to exit our app. We don't want to hinder normal use. Note exit(0) will just cause iOS to restart our app)
MDM options - (Didn't see any that would provide this functionality. Let me know if otherwise. We would like to implement it ourselves, but a 3rd party is an option)
At this point I'm just looking for ideas or knowledge. Any help would be appreciated.
Thanks
I would add a sticker on each device and then, if i need a specific device, i would push a notification with a message like: "person with the device X ..we need it in room Y " .Then it's up to the person who has it to return it (or smth).
The sticker itself would be a numbered decal... or a picture..or something like that.
It's just an idea
There is a newly introduced issue with iPhone 3.0 SDK and how it deals with the NSURL method for automatically making phone calls. It used to be that you could call a method (NSURL), pass in a string with a URL prefix (tel://, sms, etc...) and the iPhone OS would dispatch the message to the device, such as iTunes, App Store, Phone, SMS, Mail, Safari, etc... The code goes something like this:
[openURL:[NSURL URLWithString:#"tel://8005551212"]];
When the method was called the phone call would be placed automatically. With the iPhone OS 3.0 when the method is called the app pops up a dialogue box asking for confirm the phone call. This breaks several existing apps as well as one that we just pushed into the App Store for review.
Can anyone think of a fix to this issue? I'm currently at a loss for what to do and trying to decide what other ways to handle this new wrench in the works.
I blogged about this and suggested that people contact Apple and make them aware of this issue. I also recommend a fix that a friend and I were thinking about - and that is to use the same "authorization" that location aware apps have; an app knows it's location aware and asks the user if it's okay to use their location.
Again, if anyone has a fix for this issue (and that is within the realm of the iPhone SDK as to not be rejected by Apple) please let me know; I would be greatly appreciative.
Update: Julian Romero Nieto has a good description of the bug and cites the (updated) Apple documentation and shows the issue at hand. You can read his posting to Oper Radar here.
I believe this is included as a security feature - imagine an app that called a 900 number at 3am every day for 10 minutes. If you compare it to the new 'In-App Purchase' API - it's much the same.
The location API comparison is a bad example - getting the users location is a privacy concern, not a financial one.
You can't fix this issue as this is what is intended - anything you do to "fix" the issue will result in an app that won't be approved.
The user experience is considered not to be good when an app can choose to dial a number without the user's consent. It would be possible for software to dial "premium" numbers that cost the user a lot of money without them realising.
This is standard across all mobile software platforms and OS - if it just changed in OS 3.0 then this shows that it must have been an issue that initially Apple thought they could get around. However I think that Mobile Operators will have put pressure on Apple to introduce this as often then end up having to refund the user - but will have already paid out the money to the "premium" number.
I am not sure if "premium" numbers exist in the US as much as they do in Europe and that maybe the reason this is hard to understand.
The RFC for tel:// says to NOT allow autodialing of numbers via the tel: scheme.
So they have to chose between RFC compliance and breaking these few apps.
I hope the chose to ignore the RFC, at least to allow apps to keep dialing if they allow it.
I question whether this is intentional on Apple's part to push users to purchase a new iPhone if they want voice dialing - this problem breaks all of the 3rd party voice dialing apps, making them unsafe and basically useless.
Let's keep up the pressure on Apple to make this a user-configurable setting.
Perhaps you meant newly introduced feature instead of issue?
I don't think you will get Apple to remove the confirmation popup, especially if it is RFC compliance.
Lemmy quote Joel (http://www.joelonsoftware.com/items/2009/06/10c.html) regarding broken apps:
A good platform always has
opportunities for applications that
aren’t just gap-fillers. These are the
kind of application that the vendor is
unlikely ever to consider a core
feature, usually because it’s vertical
— it’s not something everyone is going
to want. There is exactly zero chance
that Apple is ever going to add a
feature to the iPhone for dentists.
Zero.
I would not want some application to make calls, send sms or even connect to internet (living in a country where unlimited mobile data plans are still far in the future) without my consent.
Certainly operator's headache when customers complain about unknown calls on bills.