I built an app that has a simple tel link:
- (IBAction) makeCall:(id)sender
{
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:#"tel://8005555555"]];
}
It worked fine when I was testing on iOS 4.
Just before I released it, I upgraded to iOS 5, and now I find that the tel link isn't working. Does anyone know if this might be something to do with iOS 5, or am I barking up the wrong tree?
UPDATE: This is for an app I built for the company I work for, and in order to fix it, my boss has to give me access to the code, which he's kind of dragging his feet with. I'll update as soon as I have access and can find out if the solution ott gave works.
The correct URL should be tel:8005555555. It could be that the // were ignored earlier.
See also http://developer.apple.com/library/ios/#featuredarticles/iPhoneURLScheme_Reference/Articles/PhoneLinks.html
Related
I am trying to run this sample project from Apple that uses ARGeoTrackingConfiguration: https://developer.apple.com/documentation/arkit/content_anchors/tracking_geographic_locations_in_ar
This sample app is supposed to show an AR camera feed in the top part of the screen, and a map view in the lower part. However, I am not seeing the camera feed, it's just black.
I suspect this is something that changed in iOS 15.4, since my colleague was able to run the app successfully on a phone with iOS 15.3.1.
Some other details:
I am seeing this issue on an iPhone 12 Pro Max and an iPhone 13 mini.
Both these devices can support geotracking and are connected to the internet.
I am in a location that has geotracking support, according to these docs: https://developer.apple.com/documentation/arkit/argeotrackingconfiguration
I updated to iOS 15.4.1 but the issue is still occurring.
I tried updating to the iOS 15.5 beta 1 and the issue is still occurring.
Has anyone else noticed this issue? Am I doing something wrong? Is there a workaround?
I filed a radar ticket as well, just in case.
EDIT: I filed a TSI request for this issue, and I got back a response saying that there is no workaround for the issue. However, it looks like the bug has been fixed in iOS 15.5 beta 2.
// Class originalClass = NSClassFromString(#"NSXPCDecoder");
// Class swizzledClass = NSClassFromString(#"SwizzledDecoder");
// SEL originalSelector = #selector(_validateAllowedClass:forKey:allowingInvocations:);
// SEL swizzledSelector = #selector(__validateAllowedClass:forKey:allowingInvocations:);
#interface SwizzledDecoder : NSObject
- (void)__validateAllowedClass:(Class)arg1 forKey:(id)arg2 allowingInvocations:(bool)arg3;
#end
#implementation SwizzledDecoder
- (void)__validateAllowedClass:(Class)arg1 forKey:(id)arg2 allowingInvocations:(bool)arg3 {
if ([arg2 isEqualToString: #"collaborationData"]) {
return;
}
return [self __validateAllowedClass: arg1 forKey: arg2 allowingInvocations: arg3];
}
#end
https://developer.apple.com/forums/thread/703735?answerId=711909022#711909022
I could think of a few options to "fix" this using Private (Apple) APIs. This approach is not super terrible and at least would unblock you from testing on a 15.4.x device (I confirmed this works on Xcode 13.3.1 and iOS 15.4.1).
As far as whether or not Apple would approve #YOLO #FIDLAR code like this in an App Store review? I can't help you there.
The real fix (we can hope for) is the next version of Xcode ships with an SDK that builds and compiles with a retroactive fix for 15.4.x.
This issue has been fixed in iOS 15.5
I just noticed that after having updated Xcode to version 10.2.1, I'm unable to see the permission request for Library and Apple Music when launching a couple of projects of mine on the simulator.
Debugging, I realised that the authorization request call goes unanswered
MPMediaLibrary.requestAuthorization { status in
// switch on status and handle it - never gets there
}
I didn't change anything in the code or configuration of my projects, and I'm very sure that this wasn't happening with previous versions of Xcode.
Just for the record, everything works fine on a real device.
Does anybody have any idea?
Am I the only one who's experiencing this?
Looks like it doesn't work on the simulator. It now just hangs, and the closure is never executed.
It did, at one time, but I guess that it no longer does.
Sort of unsurprising, as the basic media capabilities aren't really supported on the simulator anyway.
I have tested my code on device, and verified that it works, but it is annoying (not a showstopper) that it doesn't work on the simulator.
I'm using pinterest SDK on my iOS app.
code example:
[pinterest createPinWithImageURL:[NSURL URLWithString:self.imageData.url]
sourceURL:[NSURL URLWithString:[NSString stringWithFormat:#"%#/pinterest.html?al_applink_data=type%%3Dimage%%26id%%3D%#",APPLINKS_LINK, self.imageData._id]]
description:#"blabla"];
For some reason the description is missing when I switch to the pinterest app.
(the URL is working - don't go there... :))
Anyone has an idea/encountered it?
Well. Apparently it was a bug in the specific version of Pinterest app for iOS. Was fixed on 21/8. Too bad their support took 2 weeks to get back to me with this answer :(
I've written an app specifically for iOS7, and am now attempting to make it work for iOS6.
I'd really like a setting to enable warnings which highlight lines of code which won't work on iOS6. i.e. any calls to code which ONLY work on iOS7.
That way I can immediately identify any lines of code which I need to attend to before catching them during debugging.
Does this even exist?
There is two option to deal with this.
Use MJGAvailability, a drop in header file and it will make warnings if a selector is "too new".
Buy Delpoymate, it can scan your Xcode project and show you any incompatible calls.
If you use an older Xcode next to the newest, than use this snippet:
if ([self respondsToSelector:#selector(newSelector)]){
#if __IPHONE_7_0
[self newSelector];
#endif
} else {
[self oldSelector];
}
There is no way of getting a warning to appear and even if there was how would the IDE now that you would have done something to handle it like the below
if([myObject respondsToSelect:#selector(myiOS7SelectorOnly)]) {
[myObject myiOS7SelectorOnly];
}
It works the other way if you where developing an app for iOS7 and you used a deprecated method that iOS7 API doesn't use any more it would give you a warning but not the other way you will have to wait for it to turn around and crash and throw an unrecognised selector exception.
At some point I had 2 Xcode installed - Xcode 4 and Xcode 5. Xcode 4 did not have API for ios7 and it was showing all incompatibilities.
But I don't know where can you find XCode4 now and will it still show errors in ios7 code or not?
At least you can try this way.
I am trying to integrate the PayPal MPL library into an iOS app. I have a UIViewController that is creating the PayPal button like so:
- (void)viewDidLoad
{
[PayPal initializeWithAppID:SANDBOX_API_KEY
forEnvironment:ENV_SANDBOX];
UIButton* paypalButton = [[PayPal getPayPalInst] getPayButtonWithTarget:self andAction:#selector(checkoutPayment) andButtonType:BUTTON_294x43];
[self.view addSubview:paypalButton];
[super viewDidLoad];
}
The app prints the following error message to the console a second or so after opening the ViewController.
Checking Error********************
Posting Error: 2147483647
DEVELOPER ERROR: This app isn’t using a supported version of the PayPal library.
I can't find anything about this error on Google, so here I am. Any ideas on how to fix it?
I am using xcode 4.5 and iOS 6 beta to test, and the 1_5_5_070_iPhone_DevelopersPackage version of the MPL library (the latest one on the website).
I also noticed that you have to have "bundle display name" in your info.plist
Without it you will get posting error as well
I know that this is very old, but there is one more requirement. It took me a while to find out. It must not be a very big integer. I've had a version string that was something like 20141014122113 (or YMdHms) and that also set this off. After having it shortened to 20141014 everything started working. So these appear to be the rules:
You must have a bundle display name
Just digits in build number
Build number must not be too long
The problem was that the Bundle Version in the Info.plist used alphanumeric characters. It seems the PayPal library reads it and expects it to be a number.