#_implementationOnly import XXX
I would like to use but there is no any Apple documentation about it
do you know where I can find some official Apple docs about it?
what's the minimum Swift version supported for it?
is it still in beta or is it stable and official to use?
Generally all underscored properties and methods are not for regular usage (they tend to be either private APIs or development features). From the apple repo docs:
Underscored Attributes Reference
WARNING: This information is provided primarily for compiler and standard library developers. Usage of these attributes outside of the
Swift monorepo is STRONGLY DISCOURAGED.
Related
I'm looking into iOS/tvOS docs for GCKeyboard & GCMouse types.
However Apple docs seem to be missing basic info such as what I import to use a type. For example C# docs always show what libraries are needed on MS websites for types. So do Googles Android docs. I'm not seeing this on Apples docs here: https://developer.apple.com/documentation/gamecontroller/gckeyboard
Is there an easy way in ObjC or Swift to check where a type is from?
Does Apple provide any way to lookup what source file I should import for a type? How do people normally go about these lacking docs with xCode dev work?
Apple do indicate on its doc on which framework the class/object that the document referred to is relevant. See my picture for details. Its has a documentation hierarchy from the framework down to the objects and apis within it.
Specifically for GameController framework you’d use the following import
import GameController
A nice anecdote:
In older class and objects it is also customary to add the initials of the framework/library as a prefix for the name. In this case GC(i.e game contoller)Keyboard. Or UI(UIKit)ViewController. With newer libraries like SwiftUI and Combine they have stopped using the prefix.
The prefix was used due to legacy Objetive-C limitation for namespace.
New to Swift, couldn't find an answer to this with a reliable source.
I have some commented code, but would like to know if they are removed when compiled/run in Debug/Release, and if this is enforced or can be turned on/off.
If they are indeed removed, what about those instances where I really need them to be inside, e.g. some framework or something?
Thanks in advance!
If you create inline docs in a swift package, they're available to the consumer. If you provide a Docc asset, that will also be available to the consumer.
If you create a binary, that depends on how it's created and distributed.
Unless there is a security concern not to share the source code, I would do a vanilla SwiftPackage with documentation comments.
Is "connected" a private API? apple told me so.
Appstore was saying I have used a private API when I submit my app :
Performance - 2.5.1
Your app still uses or references the following non-public APIs:
connected
The use of non-public APIs is not permitted on the App Store because
it can lead to a poor user experience should these APIs change.
Next Steps
Please revise your app to remove any non-public APIs. If you have
defined methods in your source code with the same names as the
above-mentioned APIs, we suggest altering your method names so that
they no longer collide with Apple's private APIs to avoid your
application being flagged in future submissions.
Additionally, if you are using third party libraries, please update to
the most recent version of those libraries. If you do not have access
to the libraries' source, you may be able to search the compiled
binary using the "strings" or "otool" command line tools. The
"strings" tool can output a list of the methods that the library calls
and "otool -ov" will output the Objective-C class structures and their
defined methods. These tools can help you narrow down where the
problematic code resides. You could also use the "nm" tool to verify
if any third-party libraries are calling these APIs.
Is this sure? or they made a mistake?
Thank you very much!
The first thing I tried is to create a static library but later I found out that it's not supported yet. Apple Xcode Beta 4 Release Notes:
Xcode does not support building static libraries that include Swift
code. (17181019)
I was hoping that Apple will be able to add this in the next Beta release or the GA version but I read the following on their blog:
While your app’s runtime
compatibility is ensured, the Swift language itself will continue to
evolve, and the binary interface will also change. To be safe, all
components of your app should be built with the same version of Xcode
and the Swift compiler to ensure that they work together.
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded
extension, you will want to build the frameworks, app, and extensions
together. It would be dangerous to rely upon binary frameworks that
use Swift — especially from third parties. As Swift changes, those
frameworks will be incompatible with the rest of your app. When the
binary interface stabilizes in a year or two, the Swift runtime will
become part of the host OS and this limitation will no longer exist.
The news is really alarming for me a person who writes components for other developers to use and include in their apps. Is this means that I have to distribute the source code or wait for two years?. Is there any other way to distribute the library without exposing the code (company policy)?
Update:
Is Swift code obfuscation an option at this point ?
Swift is beta now, and even for 1.0 Apple has been pretty clear they're after a restricted feature set -- better to do a small number of things well than to try to do everything.
So for now, there's no way to distribute binary static libraries. Presumably that'll change sometime after Swift 1.0. For now, you can:
Distribute source
Ship a binary framework (instead of a library) if you're okay with the ABI being fragile
Use ObjC for library code
You can always combine approaches, too: e.g., implement the critical (secret) details of your library in ObjC, and ship Swift source that wraps it in a nice Swift API.
Obfuscating code written in a language that's very much subject to change sounds like a recipe for a maintenance nightmare.
I believe the whole approach is wrong. You cannot do something that is not (yet) doable by the technology you are trying to use.
Rationale: Swift is a new language, currently in Beta, and therefore changing. As I see it, this fact means not only that you are not able to ship static libraries, but that (real) developers will not be actually use third-party static libraries. What's the actual use of a library that may not work in the next release of the compiler? The issue gets bigger if you whant to use more than one library, because they might not be compatible! Therefore, even if you would be able to ship static libraries, they wouldn't be actually useful for production environment. So, what's the point?
Suggestion: write your static libraries in Objective-C (or C or whatever "non-beta"). Developers who need third-party libraries (e.g. yours) shouldn't expect them to be written in Swift until Swift is stable. You don't use experimental materials to build real bridges, right? You use well-tested, predictable ones.
From Xcode 9 beta 4, Xcode supports static library with Swift sources.
There are a number of useful business logic classes which seem to exist in both iOS and MacOSX (for example, NSMutableDictionary).
However as far as I can see the developer documentation does not indicate which they are - you're either using the Mac developer docs (in which case it will tell which version of OSX the API appeared in), or the iOS docs (in which case ditto for iOS).
Is there any documentation set (or alternative easy way) to find out which classes exist in both - i.e. the equivalent of "Available in iOS since version foo, OSX since version bar"?
A good starting point is that UIKit is for iPhone only, so any class starting with "UI..." wont be available on Mac (ex: UILabel, UITableView, etc)
Classes from the foundation Framework, starting with "NS..." are all available on MacOS, but not all are available on iOS.
In each class Reference documentation you have an "Availability" note at the beginning and sometimes a specific notes in the "Overview" section.
For example: NSAttributedString
Availability
Available in Mac OS X v10.0 and later.
Overview
iOS Note: In iOS, this class is used primarily in conjunction with the Core Text framework.
Hope this helps,
Vincent