I was wondering whether it is good to use swift programming language to create a framework for iOS application. I doubted how do we expose public interfaces in framework If I use swift. Usually ObjC framework has .h files in header folder inside the framework but swift can't.
See below post from apple https://developer.apple.com/swift/blog/?id=2
Appreciate any response on this post.
There are a few limitations regarding distributing Swift libraries, bundles, frameworks, etc...
You will need to document your API as relying on a header files only for developers to peruse won't cut it.
Mixing Swift and Objective-C is easy because of bridge technology but the technology doesn't extend to incompatible types across the bridge (struct is one of them.)
You need to package your Swift libraries in dynamic libraries. There is no way around static libraries in Swift.
Most of the early issues with naming have been ironed out, but there are still some gaps in what's available in foundation.
The C invocation is getting better with and even Swift2 deals with C function pointers in a less obscure way but Swift 2 is not out yet.
Some esoteric things you are used to with Objective-C are harder to implement with Swift. If you are going to lose the safety mode of Swift to be able to bit cast your objects, that defeats the purpose.
For most of these reasons, although I love the new language syntax, I chose to continue development of frameworks used in my app with the proven Objective-C and decided to move all the UI stuff in the application side to Swift. When Swift 2 is released, I will then reconsider this choice.
Related
I'm starting using Swift for my new audio app and I need to use Apple Core Audio library.
Let's be honest, Swift is a great language and I love it but as soon as we have to use C, pointers and other stuff it becomes really annoying to use it.
In order to make it a clear and clean interface I would to know you thoughts about interfacing Core Audio and Swift.
I thought to use C++ (for the convenients std::vector and more) or C but both require using bridging.
So my questions are:
Do you use pure Swift or C/C++Bridge when you use Core Audio?
Which one will be the faster?
I think I found the answers so I will leave it here if somebody is interested
The bridge approach is preferred. As invalidname (Chris Adamson) said in media framework talk you have to Render unto Caesar the things that are Caesar's, and unto God the things that are God's i.e use C for C API and Swift for swifty things.
Talking about performance I found an article which discusses about it. The conclusion is that for primitive type there is no problem by making all the type conversion, calling C function and making the backward type conversion. But for some type like String/char*, struct and more complicated type you could encoure performance decrease.
Btw don't hesitate to add more things if you think it could help other people.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Could you technically use Swift as a programming language for building a website / web app?
Update: Looks like a lot of people are working on this.
https://github.com/PerfectlySoft/Perfect
https://github.com/glock45/swifter
https://github.com/grzegorzleszek/HTTPSwiftServer
https://github.com/izqui/Taylor
https://github.com/crossroadlabs/express
https://github.com/IBM-Swift/Kitura
https://github.com/vapor/vapor
Official support from Apple: https://swift.org/server-apis/
In theory, of course.
Any program that can output plain text can also be used for CGI(Common Gateway Interface) which includes Swift as well.
Therefore, yes, you can use Swift for web programming. However, currently, there are no additional libraries(like there are in PHP or EJB/JSP) to make this process easy for you. Take a look at some popular web frameworks for Swift such as Vapor.
Not sure how active this topic is anymore, but in case anyone finds this in the future, I'd like to announce here that I have started working on a framework for writing FastCGI applications in Swift.
Of course you can use any Objective-C web framework (though there are rather few), and you can certainly use Swift as a scripting language to dump out HTML strings to be regurgitated by CGI. However, (I'm going to get all philosophical here) I think that settling for such an approach is not very "Swift-like" if I dare use the term. The Swift designers went through a lot of trouble to make sure that it's more than "just" Obj-C without the (constraints of) C (in fact, I almost wish they hadn't said that since it's so often misquoted). Swift is also much closer to the functional family than Obj-C (while still retaining solid object orientation AND managing to add Python-esque scriptability). This opens up a whole new world of design choices that I think need to be explored. Also, type safety... but I digress...
All this to say, I've taken it upon myself to create a modular "microframework" that will let you write web apps in Swift at a very high level. At the time of this writing, I'd classify it as a functional proof of concept, but it's still not as abstract as I'd like and is missing a number of key features that would be necessary for real-world use. Contributions are of course welcome. Hope somebody finds this helpful. https://github.com/ianthetechie/SwiftCGI
Swift works just perfect as a web programming language. You can do python like scripting (for rapid development or simple tasks) and later compile the same code with XCode (for speed):
Copy the following script to /Library/WebServer/CGI-Executables/TestCGI on your Mac (OSX Mavericks or Yosemite with Xcode 6.x installed). Make it executable with chmod +x TestCGI. With httpd started call http://localhost/cgi-bin/TestCGI. You will get the call parameters echoed...
#!/usr/bin/env xcrun swift
import Foundation
print("Content-Type: text/html")
print("Content:")
print("")
print("1. Process.argument(s):<br />")
for s in Process.arguments {
print(s + "<br />")
}
print("<br />")
let env: Dictionary = NSProcessInfo().environment
if let requestMethod = env["REQUEST_METHOD"] {
print("2. Request method is: \(requestMethod)<br /><br />")
}
print("3. Number of environment variables: \(env.count)<br /><br />")
print("4. List environment:<br />")
for key in env.keys {
print("\(key) == \(env[key]!)<br />")
}
Apple has now (12/03/15) open sourced the Foundation library (https://github.com/apple/swift-corelibs-foundation) to allow compilation on Linux Servers.
Yes, you can.
Swift does the same as ObjectiveC, but does it easier. Therefore, you could use a very simple CGI-Interface (see http://www.sveinbjorn.org/objectivecgi) to analyse and answer client requests (both GET and POST) on the server side.
Since Swift is strong in string manipulation, it will be somewhere between ObjectiveC and PHP/Perl in terms of abstraction. For many purposes, a SQLite or MySQL frontend isn't even needed. Just drop your data into some text file on the server.
Yes, you can create web apps in Swift. Tailor is one of the web frameworks which allows you to do that. Its source code is on Github.
As per the other answers, you can use Apple Swift in any number of ways as part of a web site/app implementation.
Additionally however, other companies are also developing Swift language compilers which extend the capabilities even further. For example, RemObjects recently announced that in the next major release of their Elements compiler, they would be introducing a new compiler front-end dubbed "Silver", which is a Swift compiler.
As a front end onto their existing compiler technology which already supports ObjectPascal (Oxygene) and C# (Hydrogene), this means that you will be able to develop .NET and Java applications (including Android) using the Swift language. With .NET support, that obviously means you could use Swift to create an ASP.NET web site/app.
Note that this is a native compiler for each platform - there is no source code translation/cross compilation or platform abstraction or compatibility framework involved, as there is with (for example) Xamarin. The RemObjects compiler produces platform specific, native code (i.e. MSIL for .NET, Java Bytecode for JVM etc etc). It also allows the developer to consume platform libraries natively. i.e. when developing for Cocoa, Cocoa classes are exposed directly into the language, ditto Java classes when developing for Java, .NET framework for .NET etc.
This is the case whether you are using the ObjectPascal, C# or Swift language front-ends (and you can mix and match languages in a project, if you so desire).
The 8.0 release has been in beta for a while already so existing Elements licensee's have been playing with it already. :)
In the article Cocoa with Love, you could find an example of HTTP server. It is written in Obj-C:
http://www.cocoawithlove.com/2009/07/simple-extensible-http-server-in-cocoa.html
Here is my attempt to create a swift version:
https://github.com/grzegorzleszek/HTTPSwiftServer
Browsing the web, I've found really nice swift version of HTTP server. It is worth to have a look:
https://github.com/glock45/swifter
I have integrated Lua with my ObjC code (iphone game). The setup was pretty easy, but now, I have a little problem with the bridging. I have googled for results, etc... and it seems there isn't anything that could work without modifications. I mean, I have checked luaobjc bridge (it seems pretty old and dicontinued), I heard about LuaCocoa but it seems not to work on iphone, and wax is too thick.
My needs are pretty spare, I just need to be able to call objc methods from lua and don't mind having to do extra work to make it work (I don't need a totally authomatic bridging system).
So, I have decided to build a little bridge myself based on this page http://anti-alias.me/?p=36. It has key information about how to accomplish what I need, but the tutorial is not completed and I have some doubts about how to deal with method overloading when called from lua, etc...
Do anybody know if there exist any working bridge between objc and lua on the iphone or if it could be so hard to complete the bridge the above site offers?
Any information will be welcomed.
Don't reinvent the wheel!
First, you are correct that luaobjc and some other variants are outdated. A good overview can be found on the LuaCocoa page. LuaCocoa is fine but apparently doesn't support iPhone development, so the only other choice is Wax. Both LuaCocoa and Wax are runtime bridges, which means that you can (in theory) access every Objective-C class and method in Lua at the expense of runtime performance.
For games and from my experience the runtime performance overhead is so significant that it doesn't warrant the use of any runtime binding library. From a perspective of why one would use a scripting language, both libraries defy the purpose of favoring a scripting language over a lower-level language: they don't provide a DSL solution - which means you're still going to write what is essentially Objective-C code but with a slightly different syntax, no runtime debugging support, and no code editing support in Xcode. In other words: runtime Lua binding is a questionable solution at best, and has lots of cons going against it. Runtime Lua bindings are particularly unsuited for fast-paced action games aiming at a constantly high framerate.
What you want is a static binding. Static bindings at a minimum require you to declare what kind of methods will be available in Lua code. Some binding libraries scan your header files, others require you to provide a special declaration file similar to a header file. Most binding libraries can use both approaches. The benefit is optimal runtime performance, and being able to actually design what classes, methods and variables Lua scripts have access to.
There are but 3 candidates to bind Lua code to an iPhone app. To be fair, there are a lot more but most have one or more crucial flaws or are simply not stable or for special purposes only, or simply don't work for iPhone apps. The candidates are:
tolua and tolua++
luabind
SWIG
Big disadvantage shared by all Lua static binding libraries: none of them can bind directly to Objective-C code. All require to have an additional C or C++ layer available that ultimately interfaces with your Objective-C code. This has to do with how Objective-C works as a language and how small a role it has played (so far) when it comes to embedding Lua in Objective-C apps.
I recently evaluated all three binding libraries and came to enjoy SWIG. It is very well documented but has a bit of a learning curve. But I believe that learning curve is warranted because SWIG can be used to combine nearly any programming and scripting language, it can be advantageous to know how to use SWIG for future projects. Plus, once you understand their definition file implementation it turns out to be very easy (especially when compared to luabind) and considerably more flexible than tolua.
OK, bit late to the party but in case others come late also to this post here's another approach to add to the choices available: hand-code your LUA APIs.
I did a lecture on this topic where I live coded some basic LUA bindings in an hour. Its not hard. From the lecture I made a set of video tutorials that shows how to get started.
The approach of using a bindings generation tool like SWIG is a good one if you already have exactly the APIs that you need to call written in Objective-C and it makes sense to bring all those same API's over into LUA.
The pros of the hand-coding approach:
your project just compiles with one standard Xcode target
your project is all C & Obj-C
the LUA is just data shipped along with your images
no fiddling with "do I check in generated code" to Git
you create LUA functions for just the things you want
you can easily have hosted scripts that live inside an object
the API is under your control and is well known
dont expose engine APIs to level building team/tools
The last point is just that if you have detail functions that only make sense at the engine level and you don't want to see those when coding the game play you'll need to tell SWIG not to bind those.
Steffens answer is perfect and this approach is just another option, that may suit some folks better depending on the project.
I am looking to develop an applicate for OS X with Apple's XCode for the iPhone. I have a few classes that I have defined for Visual C++, but they should be fairly cross-platform. So I would like to use those C++ classes, but my impression is that the GUI builder and everything else is built to use obj-C. Are there any examples of mixing these two languages into the same app?
Objective-C and C++ work together mostly seamlessly. You can store Objective-C objects in C++ classes, structs and collections, and vice-versa. The one caveat is that Objective-C classes won't call constructors or destructors on C++ data members unless the Call C++ Default Ctor/Dtors in Objective-C compiler option is set. But, since this is set by default on the current version of Xcode, this shouldn't be an issue.
On the whole, mixing C++ and Objective-C works very well, and is almost a universal practice in game development, since C++ provides much better support for math libraries.
This question is related to one of my others about C: What can you do in C without “std” includes? Are they part of “C,” or just libraries?
I've become curious lately as to what is really contained the the core Objective-C language, and what parts of the Objective-C I've done for iPhone/OS X development is specific to Apple platforms.
I know that things like syntax are the same, but for instance, is NSObject and its torrent of NS-subclasses actually part of "standard" Objective-C? Could I use them in, say, Windows?
What parts are universal for the most part, and what parts would I only find on an Apple platform?
If you want, giving an example of Objective-C used elsewhere as an example of what is more "universal" would help me as well.
Thanks! =)
There are only two current implementations of the core Objective-C libraries, previously known as the NextStep (hence NS prefixes) and OPENSTEP: GNUStep and Apple's OS X. On Linux, if you maintain compatibility with the OPENSTEP specification, GNUStep works very well. However, the specification is ancient, and modern code for OS X will likely not work correctly (especially in the UI area). The situation on Windows is even worse.
You can use the Objective-C language anywhere GCC supports the build target. The "NS" classes are not part of the language proper.
If you're trying to maintain compatibility across platforms in your code base, stick to C or C++, only move UI specific behavior to Objective-C.
Objective-c is C plus these keywords:
#interface, #implementation, #protocol, #end, #private, #protected, #public, #try,
#throw, #catch, #finally, #class, #selector, #encode, #"string", #synchronized,
#property, #synthesized
Plus the message sending syntax: [anObject aMessage];
EDIT
Given that you have an objective-c compiler such as GCC you still need an Objective-c runtime in order to make the above stuff work. e.g. [anObject aMessage] is actually compiled to
objc_msgSend( anObject, #selector(aMessage));
...therefore the symbol objc_msgSend is one of several that must exist at runtime. In theory this could be provided by a compiler intrinsic but in practice you are probably going to link to an Objective-c runtime library - a quick search of my hard drive shows i have three installed:- Apple's, GNUStep, and Cocotron - there are more but Apple's (open source) is without doubt the most important and influential.
With an Objective-c compiler and runtime - but without any Apple Objective-c frameworks (NSObject, etc.) - you have a fabulous and very useful C-with-Classses that is much simpler (where simpler means 'better for me') than C++.
You can a lot on Windows using Cocotron, which is a free implementation of Apple's frameworks. It's not complete, and you may run into bugs, but if you're lucky, you can compile your Xcode project as a Windows app without too many changes.
None of the class library is part of the language itself. If you want to see the core Objective-C types, look in include/objc. The core language itself, without any added library, is really scant and not particularly useful.
In practice, however, Objective-C is just about never used outside of the context of an OpenStep framework like Cocoa or GNUstep. So you could view that as the de facto standard library, in which case Foundation is almost universal. (Not 100% of Foundation is that way, but the majority is.)