sample code does not work (at least with a pod)

[skandragon]

let siren = Siren.sharedInstance

siren.appID = 12345

The latter does not work as the compiler cannot find appID:

AppDelegate.swift:32:9: 'Siren' does not have a member named 'appID'

[skandragon]

Note that while I did not put " around the ID, it still doesn't work, which is... well, damned if I can figure it out, but I started learning Swift about 3 hours ago.

[ArtSabintsev]

All fixed now based on the comment you left in #13. I thought I had included that piece of info, but I'm glad you got it up and running!

[skandragon]

Actually, it's still not working... Siren.sharedInstance works, but the compiler still claims siren.appID does not exist (along with .presentingViewController, .delegate, .debugEnabled, and even .checkVersion()

[ArtSabintsev]

what version of Xcode are you using?

[skandragon]

[skandragon]

The latest from the app store, I hope!

Version 6.2 (6C131e)

[ArtSabintsev]

try removing and re-adding the pod.

[ArtSabintsev]

To do that:

• Comment out pod 'Siren' in your Podfile,
• Run pod install
• Uncomment pod 'Siren'
• Run pod install again

[skandragon]

Exactly the same result. I also attempted a build while I had it uninstalled... same result, oddly enough.

[ArtSabintsev]

What version of CocoaPods do you have?
Run pod --version

[skandragon]

0.36.3

[ArtSabintsev]

Hmm, somehow I still have 0.36.1. Doubt that's the issue, but I'll try upgrading. However, you're saying the sample project doesn't work at all? Do you have Xcode 6.3 beta? If so, wonder if you can try it there. It works on both versions of Xcode for me (just tried it out).

Also, maybe clean the DerivedData folder

[ArtSabintsev]

and restart xcode, after cleaning that folder Then clean, build, cross fingers :)

[skandragon]

Code taken from the sample project does not work. I'm not sure if the project itself works. I can install the beta, but that will take A While with my slow internet.

[ArtSabintsev]

Just updated Cocoapods on my end and uninstalling Siren via pods in a project of mine with the 0.36.3. then will reinstall. This will help rule out fi 0.36.3 is the culprit.

[skandragon]

hmm, I don't see a directory anywhere in my project called DerivedData, or anything close. Looking in a broader search.

[ArtSabintsev]

• cd ~/Library/Developer/Xcode/DerivedData
• rm -rf *

[ArtSabintsev]

Restart xcode after doing that to flush anything else.

[skandragon]

That at least made it find out I did not have the pod installed. Trying now with an install.

[skandragon]

Same 6 errors.

[ArtSabintsev]

I can confirm the errors on my end. I wonder if the Cocoapods spec changed in what's needed in a .podspec file.

[skandragon]

That's possible, but it is very strange it finds the Siren class, but then instances of that class fail in some mysterious way. I'd almost blame Swift rather than Cocapods.

[ArtSabintsev]

Possibly. I'm experiencing this issue in Xcode 6.3b4, so that doesn't rule out Xcode, Swift, or CocoaPods.

[ArtSabintsev]

cc @getaaron - when you wake up, could you take a look? I'll look for a bit longer, but it's 3:30am here =p

[ArtSabintsev]

@getaaron

To replicate:

• Create a fresh project in 6.2 or 6.3b
• Install Siren via CocoaPods (0.36.3)
• Try call some of Siren's properties or methods, and see if the compiler cries.

[skandragon]

I'm not sure how Swift works exactly, but if it is being compiled to a .framework file, is it possible something in the Siren class needs to be marked as public?

[skandragon]

Believe it or not... changing the Siren.swift file to have this:

    public var appID: String?

removes that one error.

[ArtSabintsev]

well there goes Swift's implicit referencing. I'll play around with it for a sec.

[ArtSabintsev]

here's the thing: the class is public already. Check line 91

[skandragon]

I totally get that, and yet making the SirenDelegate protocol public, then adding 'public' in front of every non-private var or function I use makes the compiler happy.

[ArtSabintsev]

Might be time for a radar! Let me ping people on twitter tonight and tomorrow and see if anyone has an idea.

[skandragon]

It might be a different case where the source is available, vs when it is written to a framework.

[skandragon]

While confusing, https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html seems to imply that frameworks need explicit public marking.

[skandragon]

It looks like, when you're building a framework, the "public class Siren" part means "make this part of the API" and the access internally is still "internal", so each entity inside that class must be marked as public or it won't make it through the framework.

When it's included in the project directly, it shares the module, so the default still allows access.

[ArtSabintsev]

So it's only an issue because this is an external framework? That'll explain why it works if it's imported normally.

Do me a favor, make a new file Siren.h, and make sure it's target membership is set only to Pods-Siren

Add the following code in that file:

#import <Foundation/Foundation.h>

FOUNDATION_EXPORT double SirenVersionNumber;
FOUNDATION_EXPORT const unsigned char SirenVersionString[];

See if that helps at all. Remove the public scoping keywords if you can as well during the test.

[ArtSabintsev]

(I don't think that code block will do much of anything, but I realized it's missing, and I think most Swift cocoapods have a Podname.h file to avoid certain framework issues)

[ArtSabintsev]

and those issues are usually with objc-swift interoperability, which this issue clearly isn't. Thinking out-loud here. Feel free to do a pull request with the added keywords, and myself and @getaaron will take a look at the issue more closely shortly before deciding what to do.

Need sleep now =p

[skandragon]

No change when I added that file.

[skandragon]

I think the right answer is to just mark those fields and functions you want people to call as public, so they are reachable outside the Swift module (aka framework)

[skandragon]

Also marking the SirenDelegate class allows one to use it. :) I can submit a pull request tomorrow but there's no guarantee I will get all the cases right.

[ArtSabintsev]

Yup, I think you're right. Gonna ping cocoapods guys as well to get their thoughts.

[skandragon]

I think the scoping rules about modules comes into play here, and a framework is always its own module, so "internal" fails. Kinda nice really once it's understood. Night, it's 2:45am here in Central.

[ArtSabintsev]

3:45am here. I think you're right.

Btw, that file I asked you to create already exists (apparently). Auto-generated by cocoapods. Pods > Siren > Supported Files > Pods-Siren-umbrella.h

[skandragon]

Pull request created.

[neonichu]

This is expected behaviour, see https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html#//apple_ref/doc/uid/TP40014097-CH41-ID10:

public class SomePublicClass {          // explicitly public class
    public var somePublicProperty = 0    // explicitly public class member
    var someInternalProperty = 0         // implicitly internal class member
    private func somePrivateMethod() {}  // explicitly private class member
}

Everything that is not explicitly public is internal, even inside a public class.

[ArtSabintsev]

@skandragon Thanks for your help! You were right on the money with the issue and the PR. Once I got some sleep and read over the access controls docs again, everything made sense.

I accepted your PR and gave you credit in the README and CONTRIBUTORS files.

@neonichu thanks for confirming the problem.