I just want to know whether has anyone tried to handle incoming calls through the application. Like, rejecting call if it matches a blacklist, answer, hold etc through the application.?
This is a question similar to this one. And from those answers I learn that is not possible to block/reject a phone call as this would interfere with the normal functionality of the phone. The App Certification requirements clearly state that this is not allowed. In short, even if you would succeed on doing this, your app wouldn't make it through validation to the MarketPlace.
Related
Is it possible to disconnect a call programmatically? I know call kit can be used to make VOIP calls/ block users but is it possible to install an app and lets say user is busy and just by enabling a flag in the app just send them all to voicemail or disconnect without user interaction?
UPDATE
Someone marked the question as too broad. It is a simple question, is it possible to 'Programmatically disconnect a call'. not sure how this can be marked as too broad.
No, this is not possible.
Stack Overflow says my answer is too short... what else can I say? I make iOS apps since 2012, I know which APIs there are. It's hard to prove that something doesn't exist, other than saying "I would know it if it were possible."
I'm trying to develop an application with prohibited features for iOS. Swift.
I just want to know how possible they are (to make and to submit).
1 - Silencing the phone: I've seen this question in a lot of posts and the all says NO, No posible and will be rejected but... how about this app? This app silence the phone (putting ringer volume to 0) -> https://itunes.apple.com/us/app/autosilent-automatically-silence-your-phone/id474777148?mt=8
This app was summited a few years ago, i think when Celestial Framework and submitting apps with Private Frameworks was something possible, not now, so, is this possible?
2 - Blocking calls: I know since iOS 10 you can block calls with CallKit but, you need to give XCProvider a list of numbers to block. I want to block all the calls, can i give all the numbers? in the world?.
3 - Respond blocked calls with an SMS back: I can not have information about the incoming call (phone number) to send some request to a web API so it can send a message to the caller. Or do i?.
Thank you very much for all your responses...
I think your second and third point are impossible at the current situation.
You could give XCProvider a list with all number but that list would have a length of about 10^13 entries.
Apple doesn't provide a public API to recognize blocked calls and thats why you third point seems to be impossible too.
Color App for Android and iPhone can be downloaded by calling a certain number (call **COLOR (**26567)). How exactly it works? I'm interested in both the way it redirects the user on the UI level as well as the technology used.
I understand that "**" is some kind of special prefix used it US - can it be done without this prefix (i.e. by calling an typical cellphone/stationary number)?.
I am posting this question here because I believe it is related to programming. I also cannot check it as I live outside US.
The answer below is from the Developers website: http://support.color.com/home
I guess the computer-based answering machine records your number when you call it, and then sends out a text message with a direct link to the app. Quite simple and elegant solution.
How do I get Color?
The easiest way is to call *COLOR (*26567) from your device. You will instantly receive a text message with a link to download the app from the Apple App store or Android Market.
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.
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.