First of all you should know about the Windows Bridge for iOS and then you should continue to read this. The Windows Bridge for iOS is an open source project that allows you to create Universal Windows Platform (UWP) apps that can run the Windows 10 devices using the iOS APIs and Objective-C code.
In this about you will get to know about how to build a simple to-do list app in Xcode and use the Windows Bridge for iOS to bring it over to Windows 10, by keeping all of the codes in the single codebase so that the project is completely portable between platforms. If you want to follow the complete and end to end journey then you will need:
  • A PC that is running Windows 10 with the Visual Studio 2015 and the Windows Bridge for iOS installed. You can download Visual Studio from the Windows Dev Center and find the latest release of the bridge on GitHub here.
  • A Mac running Mac OS X 10.11 with the Xcode 7 installed. If you want to run the iOS project on an actual iOS device then you will need a paid Apple Developer account.
If you don’t have a PC then you can download one of our pre-built evaluation virtual machines from the Windows Bridge for iOS website. Download the package for your preferred virtualization environment and you will be up and running in no time and the package already includes Windows 10, Visual Studio 2015 and the iOS Bridge.
 If you don’t have a Mac but you are curious about developing the Objective-C on Windows 10, you will still be able to download the source code and then go through the conversion process and edit the code in the Visual Studio.
Building a to-do list app in Xcode
First of all download the initial to-do list project, which can be found here. Open up the ToDo.xcodeprojfile and let’s examine the project structure.
In the Story Board editor, we have a single UINavigationController as our root view controller and aUITableViewController that will be our main screen. Since the whole app is now a single view, a navigation controller is not strictly necessary but it leaves room for extensibility if you would like to experiment with taking the project further.
We’ve fabricated the majority of the application automatically, so the main other thing of note is the “Clear” UIBarButtonItem, which has an IBAction outlet in the clearAllTodos: system in TDTableViewController.
Now it’s a time to take a look at the classes in the left sidebar in Xcode:
  • TDItem
This is one of the clean data structure for holding the to-do list items.
  • TDTableViewController
This is where most of the logic of our app lies. This class inherits from the UITableViewController and manages for creating the new to-do items and displaying in-progress and completed to dos.
  • TDTableViewCell
This is the class which inherits from UITableViewCell and provides the layout for both in-progress and archived to dos. It uses a pan gesture recognizer to add the swiping functionality and keeps the references to its currently displayed TDItem. Its delegate is its parent table view controller which is notified when a cell is swiped left: to delete a to-do and right: to archive a to-do.
  • TDInputTableViewCell
This class also inherits from the UITableViewCell and it is used to display the input field for adding new to dos.  Just similar to the TDTableViewCell, its delegate is its parent table view controller which is notified when a new to do is added.
  • TDLabel
Finally, the TDLabel inherits from the UILabel and simply provides a mechanism for having the thick drive through its text.
That’s it, go ahead and run the app in the iOS simulator in Xcode, and you will see our app starts up and run nicely:
Take a stab at adding a couple to-do things and swiping right to archive a thing and left to erase it. On the off chance that you quit the test system and relaunch, you’ll see your rundown vanishes; we’ll inspect routines for persisting data crosswise over sessions once we convey the application over to Windows.
Now copy the project directory onto a thumb drive and then open it on your Windows machine.
Next, let’s turn the Xcode project into a Visual Studio solution.
Using vsimporter
On your Windows machine, open up the winobjc directory and navigate to the winobjc/bin. Inside this you will find the file which is known as vsimporter. Vsimporter is a command line tool that turns an Xcode project file into a Visual Studio solution. It automatically handles the Story boards and Xibs, although Visual Studio does not currently have a Story board editor, so any changes to our Story board have to be made on the Mac side. This is why we built most of the layout programmatically.
In the separate window, open your to-do list project directory in the file explorer. Select File > Open command line prompt and you will see a command line window appears. Drag the vsimporter file that is located in the winobjc/bin on top of the command line window and you should see its full path appears. With the command line window in focus, hit Enter, and then return to your to-do list project directory which should now contain a brand new Visual Studio solution file.
Using Visual Studio and the IOS Bridge
Double click on the Visual Studio solution file that was just created and Visual Studio 2015 will launch. In the Visual Studio Solution Explorer sidebar, you will see the top level solution file which you can expand to see the familiar class structure we had in Xcode. In Visual Studio there is a separate directory for storing the header files, but otherwise the structure should look the same.
 Hit F5 to run the app, wait for it to compile and voila!
Our iOS app is running inherently on Windows 10 using the Objective-C.
The main thing you’ll notice is the app doesn’t scale legitimately. Windows 10 keeps running on a wide assortment of form factors with various screen sizes, so to guarantee a decent user experience, your app ought to know about, and react to, the configuration it’s being keep running on. To finish this, we’re going to make a Class for our app in our app delegate called UIApplicationInitialStartupMode.
In the Solution Explorer, double click AppDelegate.m and beneath the very first #import, and then add the following code:
Here we are using the #ifdef and #endif preprocessor directives to check to see if the WINOBJC symbol is defined, then it will give us the ability to include the Windows-specific code. This keeps the codebase portable, since the Windows specific code will simply be ignored if we go back to Xcode and run the app on the iOS.
For a full description of the properties of WOCDisplayMode object (autoMagnification, sizeUIWindowToFit, fixedWidth, etc); see the Using SDK section of our project wiki on GitHub.
Now hit F5 again to run the app and you will see the to-do list app properly and responsively render. Go ahead and add a few to dos.
It seems like we have found a bug:
What to do when you find unsupported iOS API calls
With the little cleaning, we quickly find out that we hit bugs when adding new to dos and archiving them. In both the cases, we are using the UITableView’s beginUpdates and endUpdates instance method calls, which allow us to edit the underlying data structure and also allow us to insert and move around the rows in our table view and guarantees the validity of the whole transaction. A quick look at the runtime log shows that these methods are not supported in the IOS Bridge:
What to do?
First of all make sure you file a bug on GitHub. GitHub is the most ideal approach to reach our group to tell us what devices you require. In the event that you find unimplemented APIs, highlights you’d like to see, or bugs anywhere in the bridge, please let us know.
Next, we can use the same preprocessor directives that we used to fix the app rendering problems to create workarounds specifically for this use case. Open up TDTableViewController.m in Visual Studio and let’s tweak the methods:-
toDoItemDeleted:
 toDoItemCompleted:
toDoItemAdded:
These methods will let us easily share code between an Xcode project and a Visual Studio solution. When running the app on the iOS, we continue to use beginUpdates and endUpdates to manage the inserting and moving cells, but on the Windows we simply update the underlying data structure and call the reloadDatawhich forces the entire table view to rerender.
Hit F5 and your to-do list app should run without errors.
Persisting Data
Now, a to-do list app is not all that much use if it can’t remember you’re to dos, and currently our app keeps everything in memory, so every time you launch it you have to start from the scratch. We can do better.
Since we have such a simple use case, we can use the property list serialization to store our to-dos in a.plist file. In this way we can write out the file every time a to-do is added, deleted or archived and simply read the file on the app load.
Head back to the TDTableViewController.m and add the following methods at the bottom:
In order to store our custom TDItem object in a property list, we will need to convert it into an NSDictionary. Luckily, our TDItem implementation has a serialize method that does exactly and returns an NSDictionary.
Now we simply need to update our toDoItemDeleted:, toDoItemCompleted:, toDoItemAdded:, andclearAllTools: Methods to call [self writeToDosToDisk] right before returning and add a call to [self readToDosFromDisk] at the end of viewDidLoad.
Press F5 again to run your app and your to dos will now be remembered across launches, so you will never forget anything at the grocery store again. The new app is completely portable across the Windows 10 and iOS, so you can open your old Xcode project file up on your Mac and the app will continue to function exactly as expected.
Are you ready to try out your own app? Head over to GitHub to download the Bridge.
You can also download the complete to-do list Xcode project from GitHub wiki.

TAGS :