After trying to install OS X El Capitan onto my hard drive, I've come across a problem. When it asks me to sign into my Apple ID I do with the correct information. It then says that my username or password is incorrect. I know this is not the case because I have reset my password and tested it by signing into the App Store on my phone. Anyone else have this problem? Any fixes? Thanks.

Hello guys!Anyone out there with high CPU usage issues by kernel_task when you have two monitors connected by Thunderbolt? CPU usage at 1300%. I have to shut down one monitor.Have tested all the betas and the GM and nothing. In Yosemite works quiet.My setup;MacBookPro 15 Retina 20122.3 Core i716 GB RAM2 monitors LG

I have started to experiment with Xcode UI testing and with in my first few tests, I am observing that the app state is being retained between tests.How I kill the app completely?http://masilotti.com/xctest-documentation/Classes/XCUIApplication.html#//api/name/terminatecommand only seems to put the app in background/suspend it

I can't get NSURLSession background tasks to use client certificates.I have a simple app that creates an NSURLSessionDownloadTask from an NSURLSession that uses NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier(...).I have a custom delegate that implements:"func URLSession(session: NSURLSession, didReceiveChallenge challenge: NSURLAuthenticationChallenge, completionHandler: (NSURLSessionAuthChallengeDisposition, NSURLCredential?) -> Void)". For NSURLAuthenticationMethodServerTrust, I accept any server. For NSURLAuthenticationMethodClientCertificate, I have a hardcoded PKCS12 bundle with a single certificate and key from which I successfully create an NSURLCredential (using SecPKCS12Import), then pass that credential to the completion handler with .UseCredential.At runtime, I get the didReceiveChallenge callback for ClientCertificate, then another for NSURLAuthenticationMethodServerTrust, then URLSessionDidFinishEventsForBackgroundURLSession right away without completing the TLS handshake.If I change the NSURLSessionConfiguration to use NSURLSessionConfiguration.defaultSessionConfiguration(), the client cert is presented correctly and the download proceeds.Both tests are done with the app in the foreground.

When using an exclusion path with an UITextView, the text view is not properly wrapping the words for the first and last line in the example shown (lower text). It does render properly using word-wrap with Core Text (top example).(Hmm - the image link I provided in the HTML here works with the preview, but not the post. The example image is at: http i.stack.imgur.com/Z91ge.pngHere is the code for the UITextView (both this and the Core Text example use the same size bezier path, and both use the appropriate corresponding font and paragraph settings; wrap by word and centered):NSString *testText = @"Text Kit exclusion paths ..."; / UIBezierPath *viewPath = [UIBezierPath bezierPathWithRect:CGRectMake(0, 0, 280, 280)]; UIBezierPath *shapePath = [UIBezierPath bezierPathWithOvalInRect:CGRectMake(10, 10, 265, 265)]; viewPath.usesEvenOddFillRule = true; shapePath.usesEvenOddFillRule = true; [shapePath appendPath:viewPath]; NSMutableAttributedString *title = [[NSMutableAttributedString alloc]initWithString:testText]; UIFont *font = [UIFont fontWithName:@"BradleyHandITCTT-Bold" size:14]; [title addAttribute:NSFontAttributeName value:font range:NSMakeRange(0, title.length)]; [title addAttribute:NSForegroundColorAttributeName value:[UIColor redColor] range:NSMakeRange(0, title.length)]; NSMutableParagraphStyle *paragraphStyle = [[NSMutableParagraphStyle alloc] init]; [paragraphStyle setAlignment:NSTextAlignmentCenter]; [paragraphStyle setLineBreakMode:NSLineBreakByWordWrapping]; [title addAttribute:NSParagraphStyleAttributeName value:paragraphStyle range:NSMakeRange(0, title.length)]; UITextView *textView = [[UITextView alloc] initWithFrame:CGRectMake(0.0, 370.0, 280, 280)]; textView.textContainerInset = UIEdgeInsetsMake(0,0,0,0); textView.textContainer.exclusionPaths = @[shapePath]; [textView.textContainer setLineBreakMode:NSLineBreakByWordWrapping]; textView.contentInset = UIEdgeInsetsMake(0,0,0,0); textView.attributedText = title; textView.backgroundColor = [UIColor clearColor];It is worth noting that the Text Kit is respecting the word wrapping rules except for the first and (possibly last) line where the text does not actually fit. I need this to work with a UITextView because text entry is required, or I would be done with my Core Text example.I have tried everything I can think of to reliably work-around the issue. I don't fully understand how UITextView is working with Core Text (or I would expect to get the same results which I don’t), so any suggestions would be greatly appreciated.

In 2016 Apple announced that, starting June 1, 2016, all apps submitted to the App Store must support IPv6-only networking (see this developer news article). If you have specific follow-up questions about this policy, please feel free to post them to DevForums using the Network tag. Alternatively, if you want private, one-to-one help, you can open a DTS tech support incident. At the end of this post you’ll find answers to some of the frequently asked questions about this announcement. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" #1 — What’s the best way to check that my app works in an IPv6-only environment? You should test your app on an IPv6-only network. If you don’t have one handy, you can set up a test network by following the instructions in the Test for IPv6 DNS64/NAT64 Compatibility Regularly section of the Networking Overview. IMPORTANT If you’re testing with a WWAN-capable device, make sure to turn off WWAN before running your test. That ensures that your device is actually using the IPv6-only Wi-Fi. Note You can turn off WWAN using Settings > Cellular > Cellular Data (for English localisations outside of North America this is Settings > Mobile Data > Mobile Data). #2 — Do I need to remove all references to IPv4-only constructs (things like gethostbyname) from my app? No. It’s fine for your app to reference, and even use, IPv4-only constructs as long as it behaves correctly in an IPv6-only environment. IMPORTANT In our experience it is easier to adopt address-family agnostic APIs than to maintain separate code paths for IPv4 and IPv6, so we encourage you to do that. #3 — Will I need to update my server? That depends on where your server is running: If you have a server running on the wider Internet, the answer is no. Your server will be accessible to IPv6-only devices via DNS64/NAT64. You should update your server to support IPv6 as a matter of course, but that’s something you can do in your own time. If you have a server embedded within your iOS app (for example, a web server that allows users to transfer files to and from your app), you should make sure it works well in an IPv6-only environment. #4 — My app relies on the system’s ability to synthesise an IPv6 address from an IPv4 address. What should I do on older systems? As described in Use System APIs to Synthesize IPv6 Addresses, starting with iOS 9.2 and OS X 10.11.2 you can use getaddrinfo to synthesise an IPv6 address from an IPv4 address. Your app will be tested on a device running the latest released version of iOS, so you can assume that this support is present. WARNING Synthesising IPv6 addresses yourself is not easy. Specifically, it is not safe to form an IPv6 address by combining an IPv4 address with the Well-Known Prefix (64:ff9b::/96). This may work in some NAT64 networks but it is not a general solution to the problem. If you need to synthesise IPv6 addresses, use getaddrinfo on modern systems or see this post [1] for more background to this issue. [1] Sadly, I was unable to find the new destination for this link, at least in the time that I had available to work on it today. If you have any ideas as to what it should be, please get in touch. #5 — My app communicates with a local network-based accessory which requires IPv4 infrastructure. How can I meet this requirement? We strongly recommend that you modify your accessory to work on an IPv6-only network. There are two approaches you can take: Have the accessory support IPv6 Have the accessory support IPv4 link-local addressing (RFC 3927) Either option will allow your app to communicate with your accessory when both devices are placed on an IPv6-only network. If your accessory supports neither of these options, and it’s not possible for you to revise the accessory to do so, your accessory is fundamentally incompatible with the requirement to support IPv6. Please let App Review know about this when you submit your app. This is not grounds for rejection. The above only applies to your app’s communication with your accessory on the local network. Other aspects of your app are expected to work in an IPv6-only environment. Specifically, if your app has a way to talk to an accessory across the wider Internet, it must be willing to do that over IPv6. This will work via DNS64/NAT64 in the same way as your communication with any other IPv4-only server. #6 — App Review rejected my app, apparently for IPv6 compatibility problems. How can I investigate this? The IPv6 and App Review post discusses some of the more common reasons for why your app might encounter networking problems during review. Revision History 2024-02-06 Fixed some broken links. Fixed the formatting. Made other minor editorial changes. 2019-01-29 Refreshed various links. Made other minor editoral changes. 2016-06-23 Added FAQ #6. 2016-06-22 Added a discussion of the Well-Known Prefix to FAQ #4. 2016-05-31 Added FAQ #5. 2016-05-18 Added this change history. Added FAQ #4. Updated FAQ #1 to clarify the term WWAN and explicitly describe how to disable WWAN. 2016-05-17 Adding FAQs #1, #2 and #3. 2016-05-05 First posted.

Hi, For some reason, dirty shutdown is no longer working for me under 10.12 betaI have a script running that switches of my Mac Pro 5,1 at midnight every day. Since I travel a lot, I can remotely switch on my Mac Pro with an remotely controlled power plug switch off/switch on. Works like charm - until now. Looks like something has changed with 10.12... Anybody has an idea? Is it still working for you?Steps to reproduce:1) shutdown via terminal "shutdown -u now"2) wait until shutdown and a few minutes3) unplug the power plug and replug. Computer should start.Please note: if you do a regular shutdown, and then unplug and re-plug, computer will not start.

If I have a mapview with a tileoverlay and polyline, the view works until I zoom in close. When zoomed in, the tiles under the polyline don't render, but other tiles not under the polyline do. Xcode 7.3.1 targeting ios 9.3.Below is the minimal test case I have come up with to show this. Any ideas how to debug further? If I remove the polyline overlay, zoom works perfectly fine for all tiles. class MyController: UIViewController, MKMapViewDelegate { @IBOutlet weak var mapView: MKMapView! var overlay:MKTileOverlay = MKTileOverlay(URLTemplate: "https://services.arcgisonline.com/ArcGIS/rest/services/USA_Topo_Maps/MapServer/tile/{z}/{y}/{x}.jpg"); override func viewDidLoad() { mapView.delegate = self mapView.showsUserLocation = true; overlay.maximumZ = 15; overlay.minimumZ = 12; overlay.canReplaceMapContent = true mapView.addOverlay(overlay); var points: [CLLocationCoordinate2D] = [CLLocationCoordinate2D]() points.append(CLLocationCoordinate2D(latitude: 40.7608, longitude: -111.8910)); points.append(CLLocationCoordinate2D(latitude: 40.8894, longitude: -111.8808)); var polyline = MKPolyline(coordinates: &points, count: points.count) mapView.addOverlay(polyline) let region = MKCoordinateRegion(center: points[0], span: MKCoordinateSpan(latitudeDelta: 0.05, longitudeDelta: 0.05)) mapView.setRegion(region, animated: false) } func mapView(mapView: MKMapView!, rendererForOverlay overlay: MKOverlay!) -> MKOverlayRenderer! { if overlay is MKPolyline { var polylineRenderer = MKPolylineRenderer(overlay: overlay) polylineRenderer.strokeColor = UIColor.blueColor() polylineRenderer.lineWidth = 5 return polylineRenderer } else if (overlay is MKTileOverlay) { let renderr = MKTileOverlayRenderer(overlay: overlay) return renderr } return nil } }

Greetings,I've been struggling some time with this issue. I have this App which I'm developing a Messages App Extension. App works fine but I can't debug it. I can add NSLog sentences to check for workflow but when I try to add a breakpoint it won't stop there, even if the NSLog nearby is triggered (i.e. It doesn't stop on a breakpoint in viewDidLoad from my MSMessagesAppViewController subclass). I've tried to create a project from scratch and it works fine. It's just with this project (created from XCode 7) that I'm not able to hit any breakpoint. I've tried deleting the extension and recreating a new one with no success. When I try to debug the App target It works just fine, it's this extension target I cannot reach any breakpointAny ideas?

HiWe are making an app where the user can set the ringtone by our app. So please let me know how to set a ringtone for particular user programmatically.I have googled and found that in iOS it is not possible in any case even it is possible then Apple will reject the app.I found these all answeres hereSet ringtone in iPhone SDKHow to set music file as call tone and message tone in iphone programaticallyhttps://www.google.co.in/search?q=can+we+set+ringtone+programatically+ios&oq=can+we+set+ringtone+programatically+ios+&aqs=chrome..69i57.23214j0j1&sourceid=chrome&ie=UTF-8#q=can+we+set+ringtone+programmatically+ios&newwindow=1&start=10But these all queries/answers were 2-4 years old. Is it now possible to do this? Please let me know. ThanksGopal Devra

Transport Layer Security (TLS) is the most important security protocol on the Internet today. Most notably, TLS puts the S into HTTPS, adding security to the otherwise insecure HTTP protocol. IMPORTANT TLS is the successor to the Secure Sockets Layer (SSL) protocol. SSL is no longer considered secure and it’s now rarely used in practice, although many folks still say SSL when they mean TLS. TLS is a complex protocol. Much of that complexity is hidden from app developers but there are places where it’s important to understand specific details of the protocol in order to meet your requirements. This post explains the fundamentals of TLS, concentrating on the issues that most often confuse app developers. Note If you’re working on TLS in the local environment, for example, to talk to a Wi-Fi based accessory, see TLS For Accessory Developers. Server Certificates For standard TLS to work the server must have a digital identity, that is, the combination of a certificate and the private key matching the public key embedded in that certificate. TLS Crypto Magic™ ensures that: The client gets a copy of the server’s certificate. The client knows that the server holds the private key matching the public key in that certificate. In a typical TLS handshake the server passes the client a list of certificates, where item 0 is the server’s certificate (the leaf certificate), item N is (optionally) the certificate of the certificate authority that ultimately issued that certificate (the root certificate), and items 1 through N-1 are any intermediate certificates required to build a cryptographic chain of trust from 0 to N. Note The cryptographic chain of trust is established by means of digital signatures. Certificate X in the chain is issued by certificate X+1. The owner of certificate X+1 uses their private key to digitally sign certificate X. The client verifies this signature using the public key embedded in certificate X+1. Eventually this chain terminates in a trusted anchor, that is, a certificate that the client trusts by default. Typically this anchor is a self-signed root certificate from a certificate authority. Note Item N is optional for reasons I’ll explain below. Also, the list of intermediate certificates may be empty (in the case where the root certificate directly issued the leaf certificate) but that’s uncommon for servers in the real world. Once the client gets the server’s certificate, it evaluates trust on that certificate to confirm that it’s talking to the right server. There are three levels of trust evaluation here: Basic X.509 trust evaluation checks that there’s a cryptographic chain of trust from the leaf through the intermediates to a trusted root certificate. The client has a set of trusted root certificates built in (these are from well-known certificate authorities, or CAs), and a site admin can add more via a configuration profile. This step also checks that none of the certificates have expired, and various other more technical criteria (like the Basic Constraints extension). Note This explains why the server does not have to include the root certificate in the list of certificates it passes to the client; the client has to have the root certificate installed if trust evaluation is to succeed. In addition, TLS trust evaluation (per RFC 2818) checks that the DNS name that you connected to matches the DNS name in the certificate. Specifically, the DNS name must be listed in the Subject Alternative Name extension. Note The Subject Alternative Name extension can also contain IP addresses, although that’s a much less well-trodden path. Also, historically it was common to accept DNS names in the Common Name element of the Subject but that is no longer the case on Apple platforms. App Transport Security (ATS) adds its own security checks. Basic X.509 and TLS trust evaluation are done for all TLS connections. ATS is only done on TLS connections made by URLSession and things layered on top URLSession (like WKWebView). In many situations you can override trust evaluation; for details, see Technote 2232 HTTPS Server Trust Evaluation). Such overrides can either tighten or loosen security. For example: You might tighten security by checking that the server certificate was issued by a specific CA. That way, if someone manages to convince a poorly-managed CA to issue them a certificate for your server, you can detect that and fail. You might loosen security by adding your own CA’s root certificate as a trusted anchor. IMPORTANT If you rely on loosened security you have to disable ATS. If you leave ATS enabled, it requires that the default server trust evaluation succeeds regardless of any customisations you do. Mutual TLS The previous section discusses server trust evaluation, which is required for all standard TLS connections. That process describes how the client decides whether to trust the server. Mutual TLS (mTLS) is the opposite of that, that is, it’s the process by which the server decides whether to trust the client. Note mTLS is commonly called client certificate authentication. I avoid that term because of the ongoing confusion between certificates and digital identities. While it’s true that, in mTLS, the server authenticates the client certificate, to set this up on the client you need a digital identity, not a certificate. mTLS authentication is optional. The server must request a certificate from the client and the client may choose to supply one or not (although if the server requests a certificate and the client doesn’t supply one it’s likely that the server will then fail the connection). At the TLS protocol level this works much like it does with the server certificate. For the client to provide this certificate it must apply a digital identity, known as the client identity, to the connection. TLS Crypto Magic™ assures the server that, if it gets a certificate from the client, the client holds the private key associated with that certificate. Where things diverge is in trust evaluation. Trust evaluation of the client certificate is done on the server, and the server uses its own rules to decided whether to trust a specific client certificate. For example: Some servers do basic X.509 trust evaluation and then check that the chain of trust leads to one specific root certificate; that is, a client is trusted if it holds a digital identity whose certificate was issued by a specific CA. Some servers just check the certificate against a list of known trusted client certificates. When the client sends its certificate to the server it actually sends a list of certificates, much as I’ve described above for the server’s certificates. In many cases the client only needs to send item 0, that is, its leaf certificate. That’s because: The server already has the intermediate certificates required to build a chain of trust from that leaf to its root. There’s no point sending the root, as I discussed above in the context of server trust evaluation. However, there are no hard and fast rules here; the server does its client trust evaluation using its own internal logic, and it’s possible that this logic might require the client to present intermediates, or indeed present the root certificate even though it’s typically redundant. If you have problems with this, you’ll have to ask the folks running the server to explain its requirements. Note If you need to send additional certificates to the server, pass them to the certificates parameter of the method you use to create your URLCredential (typically init(identity:certificates:persistence:)). One thing that bears repeating is that trust evaluation of the client certificate is done on the server, not the client. The client doesn’t care whether the client certificate is trusted or not. Rather, it simply passes that certificate the server and it’s up to the server to make that decision. When a server requests a certificate from the client, it may supply a list of acceptable certificate authorities [1]. Safari uses this to filter the list of client identities it presents to the user. If you are building an HTTPS server and find that Safari doesn’t show the expected client identity, make sure you have this configured correctly. If you’re building an iOS app and want to implement a filter like Safari’s, get this list using: The distinguishedNames property, if you’re using URLSession The sec_protocol_metadata_access_distinguished_names routine, if you’re using Network framework [1] See the certificate_authorities field in Section 7.4.4 of RFC 5246, and equivalent features in other TLS versions. Self-Signed Certificates Self-signed certificates are an ongoing source of problems with TLS. There’s only one unequivocally correct place to use a self-signed certificate: the trusted anchor provided by a certificate authority. One place where a self-signed certificate might make sense is in a local environment, that is, securing a connection between peers without any centralised infrastructure. However, depending on the specific circumstances there may be a better option. TLS For Accessory Developers discusses this topic in detail. Finally, it’s common for folks to use self-signed certificates for testing. I’m not a fan of that approach. Rather, I recommend the approach described in QA1948 HTTPS and Test Servers. For advice on how to set that up using just your Mac, see TN2326 Creating Certificates for TLS Testing. TLS Standards RFC 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0 (historic) RFC 2246 The TLS Protocol Version 1.0 RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 RFC 4347 Datagram Transport Layer Security RFC 6347 Datagram Transport Layer Security Version 1.2 RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History: 2024-03-19 Adopted the term mutual TLS in preference to client certificate authentication throughout, because the latter feeds into the ongoing certificate versus digital identity confusion. Defined the term client identity. Added the Self-Signed Certificates section. Made other minor editorial changes. 2023-02-28 Added an explanation mTLS acceptable certificate authorities. 2022-12-02 Added links to the DTLS RFCs. 2022-08-24 Added links to the TLS RFCs. Made other minor editorial changes. 2022-06-03 Added a link to TLS For Accessory Developers. 2021-02-26 Fixed the formatting. Clarified that ATS only applies to URLSession. Minor editorial changes. 2020-04-17 Updated the discussion of Subject Alternative Name to account for changes in the 2019 OS releases. Minor editorial updates. 2018-10-29 Minor editorial updates. 2016-11-11 First posted.

At WWDC 2015 Apple announced two major enhancements to the Network Extension framework: Network Extension providers — These are app extensions that let you insert your code at various points within the networking stack, including: Packet tunnels via NEPacketTunnelProvider App proxies via NEAppProxyProvider Content filters via NEFilterDataProvider and NEFilterControlProvider Hotspot Helper (NEHotspotHelper) — This allows you to create an app that assists the user in navigating a hotspot (a Wi-Fi network where the user must interact with the network in order to get access to the wider Internet). Originally, using any of these facilities required authorisation from Apple. Specifically, you had to apply for, and be granted access to, a managed capability. In Nov 2016 this policy changed for Network Extension providers. Any developer can now use the Network Extension provider capability like they would any other capability. There is one exception to this rule: Network Extension app push providers, introduced by iOS 14 in 2020, still requires that Apple authorise the use of a managed capability. To apply for that, follow the link in Local Push Connectivity. Also, the situation with Hotspot Helpers remains the same: Using a Hotspot Helper, requires that Apple authorise that use via a managed capability. To apply for that, follow the link in Hotspot Helper. IMPORTANT Pay attention to this quote from the documentation: NEHotspotHelper is only useful for hotspot integration. There are both technical and business restrictions that prevent it from being used for other tasks, such as accessory integration or Wi-Fi based location. The rest of this document answers some frequently asked questions about the Nov 2016 change. #1 — Has there been any change to the OS itself? No, this change only affects the process by which you get the capabilities you need in order to use existing Network Extension framework facilities. Previously these were managed capabilities, meaning their use was authorised by Apple. Now, except for app push providers and Hotspot Helper, you can enable the necessary capabilities using Xcode’s Signing & Capabilities editor or the Developer website. IMPORTANT Some Network Extension providers have other restrictions on their use. For example, a content filter can only be used on a supervised device. These restrictions are unchanged. See TN3134 Network Extension provider deployment for the details. #2 — How exactly do I enable the Network Extension provider capability? In the Signing & Capabilities editor, add the Network Extensions capability and then check the box that matches the provider you’re creating. In the Certificates, Identifiers & Profiles section of the Developer website, when you add or edit an App ID, you’ll see a new capability listed, Network Extensions. Enable that capability in your App ID and then regenerate the provisioning profiles based on that App ID. A newly generated profile will include the com.apple.developer.networking.networkextension entitlement in its allowlist; this is an array with an entry for each of the supported Network Extension providers. To confirm that this is present, dump the profile as shown below. $ security cms -D -i NETest.mobileprovision … <plist version="1.0"> <dict> … <key>Entitlements</key> <dict> <key>com.apple.developer.networking.networkextension</key> <array> <string>packet-tunnel-provider</string> <string>content-filter-provider</string> <string>app-proxy-provider</string> … and so on … </array> … </dict> … </dict> </plist> #3 — I normally use Xcode’s Signing & Capabilities editor to manage my entitlements. Do I have to use the Developer website for this? No. Xcode 11 and later support this capability in the Signing & Capabilities tab of the target editor (r. 28568128 ). #4 — Can I still use Xcode’s “Automatically manage signing” option? Yes. Once you modify your App ID to add the Network Extension provider capability, Xcode’s automatic code signing support will include the entitlement in the allowlist of any profiles that it generates based on that App ID. #5 — What should I do if I previously applied for the Network Extension provider managed capability and I’m still waiting for a reply? Consider your current application cancelled, and use the new process described above. #6 — What should I do if I previously applied for the Hotspot Helper managed capability and I’m still waiting for a reply? Apple will continue to process Hotspot Helper managed capability requests and respond to you in due course. #7 — What if I previously applied for both Network Extension provider and Hotspot Helper managed capabilities? Apple will ignore your request for the Network Extension provider managed capability and process it as if you’d only asked for the Hotspot Helper managed capability. #8 — On the Mac, can Developer ID apps host Network Extension providers? Yes, but there are some caveats: This only works on macOS 10.15 or later. Your Network Extension provider must be packaged as a system extension, not an app extension. You must use the *-systemextension values for the Network Extension entitlement (com.apple.developer.networking.networkextension). For more on this, see Exporting a Developer ID Network Extension. #9 — After moving to the new process, my app no longer has access to the com.apple.managed.vpn.shared keychain access group. How can I regain that access? Access to this keychain access group requires another managed capability. If you need that, please open a DTS tech support incident and we’ll take things from there. IMPORTANT This capability is only necessary if your VPN supports configuration via a configuration profile and needs to access credentials from that profile (as discussed in the Profile Configuration section of the NETunnelProviderManager Reference). Many VPN apps don’t need this facility. Opening a DTS tech support incident (TSI) will consume a TSI asset. However, as this is not a technical issue but an administrative one, we’ll assign a replacement TSI asset back to your account. If you were previously granted the Network Extension managed capability (via the process in place before Nov 2016), make sure you mention that; restoring your access to the com.apple.managed.vpn.shared keychain access group should be straightforward in that case. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2023-01-11 Added a discussion of Network Extension app push providers. Added a link to Exporting a Developer ID Network Extension. Added a link to TN3134. Made significant editorial changes. 2020-02-27 Fixed the formatting. Updated FAQ#3. Made minor editorial changes. 2020-02-16 Updated FAQ#8 to account for recent changes. Updated FAQ#3 to account for recent Xcode changes. Made other editorial changes. 2016-01-25 Added FAQ#9. 2016-01-6 Added FAQ#8. 2016-11-11 Added FAQ#5, FAQ#6 and FAQ#7. 2016-11-11 First posted.

Anyone see something like this on app submission?We are developing an iMessage app with SpriteKit. The message we received from App Review was:"We were unable to install the app on iPhone. The UIRequiredDeviceCapabilities key in the Info.plist is set in such a way that the app will not install on an iPhone. Specifically, the app fails to appear in Messages."We are not having any issues on test devices on our end.Our app plist contains only one UIRequiredDeviceCapabilities key: "armv7"The extension does not include any UIRequiredDeviceCapabilities.

I've been wondering what is the memory limit for network extensions. Specifically, I'm using the NEPacketTunnelProvider extension point.The various posts on this forum mention 5 MB and 6 MB for 32-bit and 64-bit respectively. However I find that (at least on iOS 10) the upper limit seems to be 15 MB. Is this the new memory limit for extensions?

Hello everyone. I need a clarification with Core Location, please help.How exactly is GPS data passed from external GPS source that is connected via Bluetooth? After some googling I found two separate points:Core Location (CLLocationManager) is responsible only for internal GPS receiver data. For external BT sources I need to use EAAccessory and read NMEA protocol.When I connect an external source, internal GPS is switched off instantly and CLLocationManager starts providing its data. So it must work OK.Thing is, I don't have an external source to test it and I'm not that experienced in BT.I have a report that people cannot use external GPS source with my app (I use Core Location only). Though I also have an info that all navigation apps support external GPS source. So they've already solved this?Or maybe I should check Core Bluetooth out for this?My question is kind of close to this one:https://forums.developer.apple.com/thread/69717?q=gpsMaybe MFi really has a relation to that? And something can depend on GPS device being MFi or being not MFi?Or this one:https://forums.developer.apple.com/message/31679#31679Seems much closer to my topic. So if I got it right, all MFi-supported external GPS data sources should work as is via Core Location?If that's true, is all CLLocation data valid there (when using external source)? Or just altitude and position?

whenever i connect a BT peripheral and try to to read a characteristic first time, i see the "Bluetooth pairing request" popup for the user to enetr the PIN. I want to develop a custom screen for pairing PIN entry. How can we do this? I did not find any code examples or APIs in any documentation.

Let's say I want to build (iOS + Mac) free app which unlocks full functionality for paid subscription via in-app purchases API. To encourage natural growth, I would like to implement a referral program, similar to what apps like Uber have: 1. User invites their friends to my app (using a unique link or promo code) 2. Then for each activated invite they both (user who invited the friend and friend who used the invite) get a free month of access to premium version of the month.Is there a way to implement such a system with App Store and Mac App Store? Is it even allowed by IAP guidlines? (I suspect not). Now, let's say that this ideal system described above is impossible to build according to guidelines or tech limitations, but an alternative is to offer a free month of access only to users who used the invite. The user who originally sent the invite could get something else outside the app, let's say a free sticker if 10 of his friends signed up. This is easier to build and I think it doesn't contradict any guidelines. What do you think?A reply from Apple representative would be extra valuable. Thank you for your help.

I've recently been integrating Background Transfer Service into an application so that the user is able to download files in the background.I did most of my building/testing on an old iPhone 6 device that was running iOS 9.3.5 (I try to keep my previous device back a version of iOS). Background Transfer Service works great on this device. I am able to put 100+ download tasks into the queue and they all finish and report progress as expected after sending the application into the background and then re-opening the application.This also appears to work great on a new 5th generation iPad running iOS 10.3.Where things get weird is on my iPhone 7 Plus which is running iOS 10.3.1. The downloads kick off fine, progress is reported as expected in the didWriteData method, however if I background the application and wait ~10 seconds and re-open the application the progress never catches back up to what progress would have been done in the background and the progress never increments at all (it stays where it was when it was backgrounded). The didFinishDownloading method does end up getting called however it appears to wait until the very end of all the download tasks completions for that method to fire for all of the remaining tasks. So the didWriteData, didFinishDownloading, didCompleteWithError, etc. all happen right at the end in one burst. I have however had a few instances where my iPhone 7 Plus device running iOS 10.3.1 did show progress after bringing the app back into the foreground however those instances I could could on one hand. More often than not (9 times out of 10) the progress is never reported on this device after re-opening the application.I am at a bit of a loss and am wondering if there is a known bug we should be looking out for, and if so when we could expect a fix? Or if there are currently any known work arounds. From my testing/debugging I cannot get progress to work in my application on the iPhone 7 Plus running 10.3.1. I also had a co-worker test this as well and they also experienced this.In fact they went a step further and opened the Netflix application on their 10.3.1 iPhone 7 Plus device and began downloading a movie. Progress incremented as expected, they then backgrounded the application and waited ~20 seconds and re-opened the application, only to find the progress get stuck where it was when the app was initially backgrounded and it never moves. After a given amount of time of the progress not moving the download does eventually finish (the progress indicator disappears) and the Netflix movie is downloaded and able to be played. This is the same behavior I see above in my application.Any help with this would be greatly appreciated.Thanks in advance!Adam

Is it possible to write an iOS app or app extension to block an incoming call based on the area code (or some other portion of the incoming call number)?

iOS 11 adds smart quotes when typing. In macOS we can disable smart quotes on a NSTextView by setting:textView.automaticQuoteSubstitutionEnabled = NO;Neither UITextField or UITextView seem to have this property or the enabledTextCheckingTypes property. How can smart quotes be disabled on iOS 11?