It's a right fiddle to link with a Swift framework in Xamarin. Here's an example of how I did it
I recently had to add a Swift framework into a Xamarin iOS app, and it was really complicated.
There are multiple web pages that try to explain how to do this, but none of them matched my eventual solution. Therefore I thought it would be useful to share what I did, in case it’s of some use to someone wrestling with the same problem.
A client I’m working with wanted to integrate the Visa Checkout SDK into their Xamarin iOS app.
Visa have pretty good documentation on how to do this for a native iOS app, but the latest version of their SDK is written in Swift.
Now Xamarin has a tool called Objective Sharpie which lets you import an Objective-C library, but it doesn’t natively support Swift frameworks.
However with quite a bit of effort you CAN get this to work. This is what I did …
N.B. For other frameworks and/or setups these exact steps may not work for you! Take what you can from these instructions and good luck (you’ll need it!)
Instructions for binding the VisaCheckoutSDK framework
Setup a new binding project in Visual Studio for Mac, using Add -> Add new Project … -> iOS -> Library -> Bindings Library on your existing solution
Download the VisaCheckoutSDK via Cocoapods:
Make a new directory
Run the command sharpie pod init ios VisaCheckoutSDK.
This uses Objective Sharpie to setup a pod directory to download the latest SDK code.
Hack the info.plist file in the downloaded pod to make it look like it was built by the version of XCode Objective Sharpie uses:
Run sharpie xcode -sdks and note the SDK used for iPhone builds e.g. “iphoneos11.2”
In the info.plist file in the downloaded VisaCheckoutSDK pod, change the DTSDKName to the value from above e.g. “iphoneos11.2”
You can now generate the C# binding files used in the binding project you setup earlier by running sharpie pod bind
Overwrite the ApiDefinition.cs and StructsAndEnums.cs files in the binding project with the files generated in the previous step
The generated files won’t build out of the box, so need editing to get them to work. This is what I did to make them usable:
Changed enums in StructsAndEnums.cs to be long
Added Namespace of VisaCheckoutSDK.Touch to generated files
Fixed up warnings by commenting out duplicate implementations in generated code i.e. those that have the same parameters etc.
Removed empty generated interfaces
Commented out “using VisaCheckoutSDK” in ApiDefinition.cs - not 100% sure why this was necessary!
Hopefully you can then build the linking project, and hence use it in your Xamarin iOS app.
One thing to note is I had to add multiple Xamarin.Swift3.* packages in the main app to allow the Swift VisaCheckoutSDK to run. Without the correct Swift packages, the app failed to load after the splash screen on startup.
It was very difficult to consistent get the error message for the missing Swift packages, as the app often crashed before the debugger could attach and get the error message in the logs. I ended up adding all the Swift packages I could find, and then removing them one by one until the app crashed again. Clearly not a great way to do this :(
This was insanely hard, and took me a good couple of days to figure out all these steps.
Having to do this is definitely a big downside of using Xamarin versus native iOS solutions, and has definitely made me think again about when to use Xamarin for cross-platform projects.
What technology to use when developing multi-platform apps? It's complicated
Over the last 12 months or so I’ve been lucky (probably!) to use a whole bunch of different technologies to build mobile apps.
I’m often asked about what’s the best strategy for efficiently building cross-platform apps, so I thought it might be interesting to look at the pros and cons of each approach to clarify my thoughts a bit.
TL,DR; It’s complicated, and depends on your business needs.
I don’t think it’s too controversial to state that apps written using native SDKs generally offer better user experiences than those written using cross-platform technologies.
Any solution that reuses the same code on both platforms by definition can only use common elements, and therefore can’t fully utilise all native elements on an individual platform.
In particular, any solutions use a browser control and use web technologies just don’t feel as slick as one using native SDK elements.
For most businesses, when they want a mobile app they want both an iOS and Android app.
It goes without saying they want to reduce the cost of doing this, but the UI quality they are happy with is a key factor in deciding what is the appropriate solution.
I inherited a project using Ionic, a Javascipt/Cordova/Angular framework that - as their website states:
… emulates native app UI guidelines and uses native SDKs, bringing the UI standards and device features of native apps together with the full power and flexibility of the open web
Once I’d got back into slight craziness of Angular, it was quite a nice way to develop. In particular the app worked pretty much identically on both iOS and Android without any extra effort.
The app is a pretty simple database-driven solution that presents information and checklists for workers when they are on a remote site. In this case functionality is much more important than a superslick UI.
Usuability was definitely more “functional” than “crafted” (although well designed), but TBH despite a lot of effort spent polishing the code, you can tell it’s a web app underneath.
Animations and transitions don’t feel native, and other UI elements aren’t quite right too - not surprising as they’re being emulated in a browser control.
For this particular app, using Cordova and Ionic was actually a decent solution. Development costs were definitely reduced compared to building two native apps, and the trade off with reduced UI quality was probably the correct one.
Despite having many years experience using C#/.Net I’d never considered using Xamarin before, mainly because it was quite expensive at first before Microsoft bought it a few years ago.
I inherited an app using Xamarin that needed completing, and I was pleasantly surprised how productive it was. All of the business and data logic could be shared across platforms, which was great saving of both development and testing time.
The app downloads lots of information from a web-based CMS to display to the user, as well as allowing them to build up a local photo gallery.
The downloaded info is stored in a local Realm database, which has a nice cross-platform Xamarin implementation.
Each platform has its own native UI code (which obviously means it was written twice). However this isn’t quite as inefficient as it sounds as much of the code is simply binding to UI elements to data objects and watching observable events in the shared data library.
The main non-reusable work is designing the native layouts for each platform. This does mean you can design the best UI for each platform, and in consumer-focussed apps this may be an acceptable trade-off.
For apps where the user experience is important, and there is a lot of business/data logic that can be shared, I’d definitely recommend Xamarin as a good solution.
I should also mention there is a “Xamarin Forms” option not used here, a cross platform UI solution that uses native elements - obviously only UI elements common across both platfors. In some cases this may be an even better solution, especially for simple UIs.
Separate native apps
For a few of my clients I’ve built two separate versions of the same app for iOS and Android, using the native SDK for each.
Clearly this means none of the code is reused, but I don’t think it’s necessarily as inefficient as it sounds.
In both cases I built most/all of the iOS app first, which meant the UI/navigation/business logic could be iterated on until everyone was happy with it. Then once all of the problems had been solved, it was “simply” a case of reimplementing on Android - a task that was really easy (if a little boring) as it was very well defined what needed to be done.
As a small team of one, this is actually a pretty efficient way of working, and probably wasn’t much slower than the Xamarin solution given above. This is especially true for apps where most of the work is in crafting nice UIs rather than writing complicated business/data layer code.
Other advantages of building separate fully native apps, including having the quickest way of implementing new technologies, plus the code written in a way that is easier to find developers to maintain and extend.
Clearly there are other cross-platform solutions out there - in particular React Native looks very interesting - but as I haven’t really used them I won’t comment on them here.
As an experienced C# developer, for projects where I get to choose the tech stack I’ll definitely consider using Xamarin again. Having native UIs and reusable business/data code is probably a good compromise in may circumstances. If you have existing .Net development skills, I’d definitely recommend looking into going down this route.
For larger teams, or on consumer-focussed projects where UI quality is important, building native apps per platform can result in the highest quality experience, even if not the cheapest solution. Finding developers with native skills on each platform is probably easier too.
Using Cordova/web-based technologies can be the cheapest way of building cross-platforms mobile apps - especially if you already have those skills in house - but there is definitely a drop off in the UI quality compared to native solutions.
My new Alexa skill to help you take a positive view on life
Amazon Echos are slowly taking over our house. We’re up to 3 now, and mainly use them for tasks like:
Controlling the TV/Amp/Sky/AppleTV/BluRay/FireTV via our Logitech Harmony
Adding items to our shopping list in Todoist
Listening to music (Spotify) and the radio (BBC streams)
Setting timers while cooking (so much more reliable than Siri)
Voice assistants are still a long way from being great general purpose helpers, but for a subset of well-defined tasks like these they are fantastic!
Developing Skills for Alexa
I’ve already built a Halesowen Town Alexa Skill (of course!), which was a great learning experience. I’m hosting the NodeJS code for the skill on AWS Lambda, and doing it this way makes it pretty easy to get something up and running.
I was looking to build another skill - to be honest mainly to get a free Alexa hoodie from Amazon for any new skills published in December :)
An aside: Social Media Negativity
Going on Social Media these days can be a pretty depressing experience.
I’ve just about given up on Facebook, and although I get lots of good stuff from Twitter, it can be a pretty negative place - especially when the current divisive political climate on both sides of the Atlantic is being discussed.
Just Say Yes!
I also find during the cold Northern winters it’s easy to get a bit down.
A few years ago I embarked on my "Something New Every Day" project. This was possibly (and surprisingly) one of the hardest things I’ve ever done, but the main upside was I tried really hard to say yes to anything anyone suggested to do - any way of ticking off another new thing for the day!
I wanted some way to recreate this positive experience, so hence I built a simple new Alexa Skill called "Miss Positive"
All the skill (she?) does is answer any question you ask with a randomly selected positive answer.
Technically this was very easy to do of course, especially using the pre-written template for a fact-based quiz, but actually I’m really happy with the result. If I’m wavering on whether I should do something, I ask Miss Positive and she puts me right!
If you want to give Miss Positive a try, follow the instructions at this page
If I'm starting a new iOS project, which language should I choose?
I’ve been crazy busy over the last few months - a good problem to have, but it means I’ve had no time to blog on here 🙁
I’ve been switching between loads of different technologies to build mobile apps during that time. I thought it might be interesting to share my experiences switching between Objective-C and Swift, and the pros and cons of each.
It’d been a while since I’d worked in Objective-C, but I took on a project for one of my clients to enhance and modernise a couple of their apps which hadn’t been touched in a while.
To be honest the original code was pretty awful - they’d been let down by some contractors in the past and it took me a while to get my head around how the app worked.
Objective-C is notorious ugly to look at, with all those square brackets in the method calling, but once you get used to it I find it pretty productive to use.
I think knowledge of iOS APIs is by far the most important thing when developing on iOS, not the particulars how to type the code to call the API methods required.
The biggest plus point for Objective-C is the speed and stability of XCode and the compiler. After mostly doing Swift development in the last year or so, it was really nice to get fewer mysterious compiler problems.
I strongly suspect Apple still do most of their internal development using Objective-C, and until they move over wholesale to Swift there will be less internal pressure to improve XCode to handle Swift more reliably.
The main downside was that more and more of the code examples out there on the web - especially for the more modern APIs - are now in Swift. Less opportunities for “Stack Overflow copy-and-paste” development 😊
Most of my own apps are written in Swift now, and I’ve been doing the usual summer updates to keep them up to date for iOS 11 - and this year also for the challenge of iPhone X and the notch.
I must admit I do like Swift, and in particular the way it forces you to think hard about nullability of objects. This enforced type safety can be a bit painful at times (all the “!” and “?”s) but I trulythink you end up with more reliable code in the end.
However, as I mentioned above, XCode and the compiler are MUCH less reliable when using Swift. Quite often I’ve seen it do a poor job of recompiling changes, so you’re never 100% clear if you are seeing the latest code in the emulator. A restart of XCode usually fixes it, but that’s a real productivity hit.
The Swift compiler is also feels noticeably slower than the Objective-C compiler. All those small delays soon add up.
Also Swift is still a bit of a moving target, and once again we have Swift 4 and changes to the language. These seem to be getting fewer over releases, but I really hope the language gets to some sort of stability soon.
So which language will I choose for new projects?
I think I’ll still choose Swift for any new projects when I have a choice. Apple have strongly signalled this is their preferred language going forward, and as a language I do prefer it to Objective-C.
However after a few months back using Objective-C, I’ve really enjoyed the stability and speed of the tools. Let’s hope the Swift tools can improve to a similar state soon.