I need a way to have an iOS application that can accept a message on a device connected via USB, query a bunch of data about the device and return a response with this data.
I am brand new to iOS and swift development so I need something that is;
Simple
Uses CocoaPods (due to lack of ios support in Swift Package Manager)
NOT require distribution via the App Store (which I believe rules out using APN)
I have tried the following:
BlueSocket: https://github.com/IBM-Swift/BlueSocket
This can probably do the job but is very low level and require lots of work around handling buffer sizes, etc. So a REST solution might be a better
Kitura: https://www.kitura.io/
This seems ideal. However, it only appears to support Swift Package Manager which makes it a big PITA to implement currently (reminder; swift/ios newb here)
CoacoaHttpServer: https://github.com/robbiehanson/CocoaHTTPServer
This looks ok, however I can only find Objective-C examples. Would prefer to have something that includes solid Swift examples (also, the repo doesn't look like it's been updated since 2015)
Are there any other approaches I should consider that I haven't listed here?
You may want to check https://github.com/IBM-Swift/Kitura-HelloWorld-iOS.
I wrote a couple of blog posts about it https://developer.ibm.com/swift/2017/03/13/kitura-ios/, https://developer.ibm.com/swift/2017/12/08/kitura-ios-part2/.
Note that it is a demo repository, I do not know if IBM will support Kitura on iOS (it is supported on Linux).
Related
I've been struggling to find how I could potentially implement a simple (iOS) app that would be able to block all connections to a specific domain (to prevent the user from accessing a specific social media platform for example, even from another app).
The information that I have found so far is that I should probably create a Packet Tunnel Provider within a Network Extension and ask the user to add VPN configurations, but I haven't found any example code that would show exactly how to implement this.
Do you have any idea how I could do that in a simple way (block all connections to a specific domain)? Is there a framework/library that I could use to do it easily?
Thank you!
Well, it would not be easy, but you can do it.
Sample code from Apple could be found here and here. This project is for iOS, but it may be on deprecated Swift version, so you will need to do some work to launch it now.
The part you are interested in the SimpleTunnel sample is FilterDataProvider and FilterControlProvider, other things you can omit, because the purpose of this sample is to demonstrate a lot of abilities.
There is also a sample for macOS that is more focused on your needs, and macOS SDK is alike to iOS, but less powerful.
You may want to see this video to sort things up in mind.
There are a lot of firewalls solutions for ios and mac, and some of them are opensource
The part you are interested in the SimpleTunnel sample is FilterDataProvider and FilterControlProvider, other things you can omit, because the purpose of this sample is to demonstrate a lot of abilities.
You will need a developer account, a network extension capability assigned to an application identity, and proper network extension entitlement file a to run things up.
There is a way to sign it manually for development without account&capability, but to distribute you will need it anyway.
For some restrictions you may be needed to install MDM profile on the device.
I am looking to implement firewall/network filtering functionalities for macOS.
I am looking at the most secure way to do this, i.e. trying to make sure no network traffic is missed, and that my filtering cannot easily be by-passed.
After searching around, I can see that Apple has deprecated Network Kernel Extension. They recommend now to use the Network Extension framework.
However, I can see that firewalls for mac, for example Lulu and Little Snitch have moved to using Kernel Extension, and not the Network Extension framework.
Is there a good reason to do so? Do Kernel Extension allow a deeper, more secure filtering?
for example Lulu and Little Snitch have moved to using Kernel Extension
I can't speak for Lulu, but Little Snitch at least was developed long before the "Network Extension" API was introduced, it certainly didn't "move to" the NKE API. According to an article on their own blog it looks like they're actively investigating moving to Network Extensions. I suspect that as long as NKEs work without restrictions on all macOS versions they support, they'll keep using those, in order not to have to ship different back-ends simultaneously. But they probably have some kind of internal prototype using the newer APIs already to make sure they're prepared for when NKE APIs are finally removed from the OS.
If Network Extensions support your use case, you should probably go with them. If they don't, you should file Enhancement Requests with Apple, or you will be out of options when NKEs stop working.
Edit: To deploy NKEs, you will essentially need a kext signing certificate (Developer ID Application + Kext) if you don't already have one. The alternative is forcing your users to disable SIP's kext signing requirement, which is neither sensible nor reasonable in most cases. I hear Apple has made it much harder to obtain such a certificate in recent years.
I am making an app that involves sending and receiving files from one iPhone to several other iPhones. I did a lot of googling and came nowhere in finding the classes that support the above said features. I am wondering whether it is possible and if it is possible what are the classes that i can use to do that
Take a look at my library https://github.com/abdullahselek/Merhaba
you can send data with Bonjour networking
OSX has functionality not available in the iOS SDK, and occasionally I'll find an answer like this one: no route.h on the iPhone SDK, that says "just copy the header file from the Simulator (or OSX) SDK and it'll work fine."
That seems suspect to me on multiple levels, including App Store approval, but then I read something like this from an Apple employee who says "if you're using sys/route.h declarations on iOS for an App Store app, please get in touch with me...", which sounds like tacit approval (or a ruse to catch misbehavior :)
Anyone know where the official line really is, and whether something like this is at all safe to do in production code? I'm particularly interested in lower-level BSD functions and whatnot for portability, as opposed to undocumented Objective-C methods.
I would not regard that comment on the Apple forums as tacit approval. It sounds like they're just trying to decide if some additional BSD APIs should be added for use in iOS apps.
In general, if there isn't an iOS header available for a function, then it's considered a Private API (for example, something under https://developer.apple.com/library/ios/). The official policy on Private APIs is that they're not to be used in apps distributed through the App Store.
Now, you can certainly use them for personal/hobby apps, or apps that you deploy in-house (Enterprise Distribution).
If the APIs you're talking about are APIs that are publically documented for OS X, and you can get them to work for iOS by copying headers, then they're probably part of the Darwin source base. It's very likely that they'll continue to function in future versions of iOS, although that's not guaranteed. Of course, nothing is guaranteed (really), as public APIs get deprecated, too.
Then, there's the issue that not all review checks are automated (I don't work for Apple, but can deduce this from things I've seen get through review). It isn't that unusual for apps to be approved with Private API usage, although if they get popular, Apple frequently pulls those apps from the store within a couple weeks. The review process isn't perfect.
So, my answer is that if you're submitting to the app store, don't expect copying in headers to work.
P.S. If you can tell us specifically which BSD function you're referring to, we might be able to give you a better answer.
P.P.S. The answer you link to about Route.h is from Grant Paul, who writes quite a bit of non-App Store software.
Additional useful information on Private APIs and the App Store
Apple never knows what header files you use - the danger of course is the definition from the copied file is close to, but not exactly, what iOS uses. If this file is important, or a few select files, post a question on Apple's internal forums and you will surely get an answer to such a question. Failing that, burn a DTS incident (you get two a year, I almost never use mine).
I am a developer working on a robotics application for iOS. I do not intend to submit this app to the app store, nor do I have any wish for suggested methods to be apple approved....
I am trying to get bluetooth working, and I think a good place to start is to try modifying the existing apple frameworks. Is it possible for me to modify the frameworks so that when they are built to my iOS device the frameworks will be modified for the app (but not other apps on the same device)?
As a matter of fact, you can!
Objective-C allows you to "swizzle" methods to override their default behavior, and yet still call the original implementation if you want to. You can do this for any number of Objective-C methods, as many times as you want.
If you wish to override behavior that is present in C functions, you will need a little bit more control over the platform. Jailbreaking allows you to use the full power of Jay Freeman's CydiaSubstrate to hook or swizzle both Objective-C methods and C/C++ functions.
While I don't recommend the use of MethodSwizzle per se, the following URL has a good discussion of swizzling http://cocoadev.com/wiki/MethodSwizzling.
But you should really use CydiaSubstrate's MSHookMessageEx and MSHookFunction instead. Especially since you're not submitting anything to the App Store.
Now regarding Bluetooth, I've done extensive work in this field (I developed Celeste, which is a systemwide tweak providing vanilla Bluetooth OBEX support to system apps on iOS). I suggest you look into using something like BTstack, which provides you with access to the bluetooth module from the HCI to RFCOMM levels, and supports things such as SDP and pairing, which you will probably need. It also has the added benefit of not requiring method swizzling, which some people seem to think is some sort of satanic ritual that should be avoided at all costs.
Aside from categories (which extend the functionality of base classes delivered in those frameworks), I don't believe you can "modify" the existing Apple frameworks per se. A better course of action might be to simply create your own framework (or find somebody else's open source, commercial or simply third party framework) and then build that framework into the app that you install onto the iOS devices you want to work with.