Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-1226] Marking a method as unavailable in iOS Extensions should allow me to use APIs unsafe for extensions #43834

Open
swift-ci opened this issue Apr 14, 2016 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-1226
Radar rdar://problem/34949130
Original Reporter kaybutter (JIRA User)
Type Bug
Environment

Xcode 7.3 with Swift 2.2

Additional Detail from JIRA
Votes 10
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 51ba9fd65347cc3638554b002b1937f1

Issue Description:

I am writing a dynamic framework used both by an iOS application target and an iOS extension target. The framework is marked with the "allow app extension API only" flag.

The following swift code from the framework will fail to compile:

@available(iOSApplicationExtension, unavailable)
func test() {
    _ = UIApplication.sharedApplication()
}

The Objective-C version, using NS_EXTENSION_UNAVAILABLE will compile:

- (void)test NS_EXTENSION_UNAVAILABLE("don't use this in extensions") {
    [UIApplication sharedApplication];
}

Expected Behavior:
@available(iOSApplicationExtension, unavailable) should behave like NS_EXTENSION_UNAVAILABLE. Methods or classes marked as available in extensions should be allowed to use APIs not available for extensions.

@swift-ci
Copy link
Collaborator Author

Comment by Scott Berrevoets (JIRA)

I'm running into this same problem (Xcode 8.3/Swift 3.1). Are there any known workarounds?

@tjw
Copy link
Contributor

tjw commented Oct 12, 2017

We're hitting this as well when working on app extensions that use our existing frameworks. Those frameworks have been marked as being annotated for reviewing extension unsafe API in the ObjC parts, but doing so for the Swift parts doesn't work. This makes Swift difficult/impossible to use for frameworks where some pieces of the framework might need to be called from app extensions.

Also, comically, if I add an explicit availability check:

class Example {
    @available(iOSApplicationExtension, unavailable)
    func x() {
        if #available(iOSApplicationExtension 11, *) {
            _ = UIApplication.shared
        }
    }
}

then I get a warning "unnecessary check for 'iOSApplicationExtension'; enclosing scope ensures guard will always be true" ... so at some level it seems the compiler is tracking the needed state to make the feature work correctly.

@tjw
Copy link
Contributor

tjw commented Oct 12, 2017

Logged as Radar 34949130 (Annotating Swift framework code for app-extension safe API doesn't work)

@tjw
Copy link
Contributor

tjw commented Oct 12, 2017

Here is a possible fix <tjw@6e57b861d37eab8cf5ccf888865bdad5019227b9\> , which seems reasonable to me. Right above this is a less permissive early-out for "same unavailability" checks that could maybe be removed.

@tjw
Copy link
Contributor

tjw commented Oct 12, 2017

Also submitted as a pull request. #12410

@BasThomas
Copy link
Contributor

It looks like this has been fixed and the pull request has been merged. Should the state of this issue reflect that?

@swift-ci
Copy link
Collaborator Author

Comment by Daniel Jalkut (JIRA)

I came across this bug while searching for a solution to the original problem. I am happy to say the
@available(iOSApplicationExtension, unavailable)
Annotation seems to work as expected in Xcode 12 with Swift 5.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants