January 27, 2016 2:12 pm

Visual Studio Walkthrough for iOS Developers


In the first post in this series, we talked about using the Windows Bridge for iOS to create Universal Windows Platform (UWP) apps that can run on Windows 10 devices using existing Objective-C code. Our third post explores using the iOS bridge to bring Storyboards and Auto Layout to Windows 10. This post will focus on getting Xcode and iOS developers familiar with the Visual Studio IDE, whether starting from scratch or using existing code from a source repository, such as GitHub.

Modern IDEs, especially those for app development, are becoming very similar. While each may have its own nuances and intricate IDE features, they will all generally offer the same key functionalities. There will be a way to load projects and solutions, lay out controls visually, work with code, and debug with some level of emulation. As a result, once you learn the basics of one IDE, you’ll find you can pretty easily transfer that knowledge to the others.

It is no different moving between Xcode and Visual Studio. In fact, the team at the One Dev Minute blog on Channel 9 put together an excellent summary video that quickly shows a feature-for-feature comparison when putting together a sample app, though it shows older versions of Visual Studio and Xcode.

The first step in working with any IDE is loading up a project. In Visual Studio (click here to get the free Visual Studio 2015 Community edition), the steps are basically the same as starting a project in Xcode. Just point to File → New → Project.

1_newprojectIn this case, we’ll pick a project template from a list of installed templates, set the application and solution name, and select the directory where the files will be stored:


After clicking OK, the template creates a runnable UWP app that compiles and runs but contains no UI or data. We selected the Blank App template above. As with all templates, this will create the minimal required files needed for creating an app:

  • Packages, libraries, frameworks, and references needed for the app to run
  • A manifest file (appxmanifest) that describes your app (its title, description, start page, et cetera) and lists all the files that your app contains
  • Code files for your app
  • Set of logo images to display in the start menu
  • Windows Store app image
  • A temporary key file (.pfx) for signing and deploying your app during development
  • Splash screen
  • XAML (xaml) page to get you started coding your UI


Note: If this is the first UWP app you’ve created with Visual Studio, you will need to set your device to “Developer Mode” in order to run and build applications. In fact, you’ll get the prompt whether or not your device is in developer mode.

With the project loaded into Visual Studio, let’s explore some of the main windows in the IDE.

Note: The following assumes you’re using the default window layout in Visual Studio. If you change the default layout, you can reset it in the Window menu by using the Reset Window Layout command (in the toolbar, click Window → Reset Window Layout.

The first thing you will notice is the code window. This window is where you will work directly with the code files used in your application. The code window is tabbed. Every file you open starts a new tab. If you have too many tabs open to be displayed across the top of the window, you can use the drop down arrow on the right to navigate between files.


In the code window, Visual Studio provides an amazing Intellisense (or code completion) experience. Just start typing and contextually relevant objects, properties, and methods will be suggested and then filtered down with each keypress.


For XAML UI files, you will have the option of editing the XML directly or using Design mode and the drag-and-drop WYSIWYG tools for quickly laying out the UI. Many developers often start in Design mode and then jump into the XML to fine tune. Here, we have opened the toolbar and dragged a variety of UI controls (textbox, button, textblock, etc) onto the design grid:


Note: If Design Mode does not show up for you, right-click your project file and, in the application properties page, under Targeting, adjust your target version to the earliest setting. In order to show design elements, the target needs to be equal to or less than the version of Windows installed.


Left and right of the code window are a number of panes for working with the project files. The one you will use most is the Solution Explorer. The Solution Explorer is the hierarchical representation of the file structure of the project. Clicking files in this pane will load the selected file into the code window. Right-clicking and selecting “Properties” from the context menu will load the properties pane for the selected file.

For files, the properties pane is useful for displaying file information or specifying how files are compiled.


When working in Design Mode, the properties pane is how you specify attributes of UI elements (such as control names, borders, and text) and even assign actions.


When in Design Mode, the Toolbox pane also allows you to drag and drop UI controls directly onto the canvas.


Team explorer is the pane that contains all the functionality for connecting to source control and managing builds, branches, and other settings.


At the bottom, you have the output window and error list. This list is useful for getting insight into the steps the compiler goes through and any errors or warnings you may encounter.



It is important to note that all of the windows and panes are modular and can be dragged and docked to set locations within the main Visual Studio window or dragged out altogether. Find a layout that works best for you.

Now that we have loaded up the code and had a look at the various Windows and Panes in which we’ll be working, what’s the one thing every developer does as soon as a project is loaded? Try to compile it. In Visual Studio terminology, this is called “Build.” Generate the application executable/package causes Visual Studio to analyze the code, search for errors in syntax or logic, validate all references and links, and generate the application executable/package .

When building, you have a couple of configuration options. By default, solutions are loaded in “Debug” mode. Debug mode includes full symbolic debug information in the compiled files to enable easy debugging and does not optimize the binary it produces. You can also change the project to release mode. Release turns on the optimizer and the extra debugging information is not included. Release mode is that last step for final QA, performance testing, and publishing to the app store.

There is a handy dropdown in the upper toolbar that allows you to quickly change between debug and release mode.


You are also provided with a set of emulation options. You can debug in a Simulator, your local machine, or even directly on a device.


Just select your build options and then click F5 or, from the toolbar, click DEBUG → Start Debugging. The build will start, and once deployed, will launch on the device you selected. Below is a sample of a deployed app using the Simulator. Because the simulator is running on the PC, we choose x86 architecture. If it we were being deployed to a device, you’d choose ARM.


As you build and test your app, you will no doubt encounter errors or need to step through the code. Visual Studio has a great set of debugging tools.

You’ll find some of these debugging tools in a few tabbed panes along the bottom that appeared when you launched the app in Debug Mode:


These panes serve a variety of purposes while debugging. At a very high level…

  • Autos—displays variables used on the preceding lines while debugging
  • Locals—displays all variables that are currently in scope
  • Watch—displays selected variables that you want to watch while debugging
  • Call Stack—displays where you are in the code at the current breakpoint
  • Breakpoints—displays all defined breakpoints in the app
  • Exception settings—allows you to define when to break execution when exceptions are thrown
  • Command Window—allows you to execute commands within the VS IDE
  • Immediate Window—allows you to execute statements and commands during debugging
  • Output—displays status messages for various features in the IDE

To use the advanced debugging functionality, you will need to define breakpoints throughout your code. You can do this from the context menu or by simply clicking in the far left margin:



A red circle will be added to the left margin indicating that a breakpoint has been set. With a breakpoint defined, run your app by pressing F5. When the executing assembly hits the breakpoint, execution will be halted. From here, you have a couple of options. Just like in Xcode, you are able to Step Over, Into, and Out of blocks of code while debugging. Visual Studio provides a toolbar button with a corresponding key on the keyboard:

  • Step Into. Pressing F11 will continue the execution of the code one statement at a time. If the current line is a method, step to the first line of that method. This is the most granular way to chase down every line of code that is executed.
  • Step Over. Pressing F10 will execute the current line. If the current line is a method, it will execute the entire method and proceed to the next line of the current block.
  • Step Out. Pressing Shift + F11 will execute the remaining code in the current block and return the cursor to the calling method.

As you step through your code while debugging, the various debugger windows will be populated with information that will allow you to track down issues in the code more easily.


In many cases, you will be working with an existing code base that resides in source control of some sort. Whether it be TFS, Subversion, or GitHub, the process for loading it up is all basically the same.

Let’s take GitHub, for example.

First, you want to make sure you have the GitHub extension for Visual Studio installed (if you didn’t already select the option when installing Visual Studio).


Once the GitHub extensions are installed, let’s “commit” or “check in” the project we just created to our GitHub repository.

To commit a project to a GitHub repository, in the Solution Explorer pane, simply right-click your solution and select “Add Solution to Source Control.”


You will be presented with a “Choose Source Control” popup window. For this example, let’s choose Git.

The GitHub extension will then create a new local repository. You can see this by toggling Team Explorer and expanding “Local Git Repositories.”


Right-click your newly created repository, then click “Open.” On the Team Explorer Home screen, click the “Sync” button, then click “Publish to GitHub.”


Enter your GitHub credentials (if required), then click the “Publish” button.


This will create a new remote on your GitHub account. From here, go to the Team Explorer home screen and click the “Changes” button. Enter a “Commit Message,” then click the “Commit” button.


Once committed, “Sync” your changes to the server by clicking the Sync link on the commit success screen and again on the “Synchronization” screen.


The code on your local repository and the code on the server are now synchronized.

With code already “committed” and “synced” to GitHub, loading a solution is as simple as providing the path to your repository. In the Team Explorer pane, select “Manage Connections” and then the “Clone” link.


In the supplied field, enter the URL to your repository. Make sure the path to your local repository is OK, then click the “Clone” button.


That’s it! You’re now connected to source control and can commit, sync, and manage code and builds. If you double-click your newly created repository, click the “Open” link, and select the “.sln” file, Visual Studio will go out, grab the code, and then load the solution.


As you can see, working in Visual Studio is not very different than working in Xcode. Whether creating and loading projects, working with code, or debugging, the Visual Studio toolset should feel familiar to you.

For more information on Visual Studio and what you can do with it, check out these links:

For more information regarding Windows Bridge for iOS

Updated April 6, 2016 12:12 pm

Join the conversation

  1. Are there *any* stats on *any* companies/developers actually embracing this bridge? I am really curious on the adoption of this, as you are competing with 1B *active* iOS devices (as of this week) and are trying to lure them *backwards* onto a platform with only 200M installs. I am trying to understand the value proposition in that and maybe you can explain it in more detail to help a developer out.

    Conversely (and/or additionally), it really seems you should be listening to your developers and building a bridge *OUT* to other platforms in addition to the (backwards) ones you have already built: http://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/10027638-create-a-ubiquitous-net-client-application-develo

    You can then charge us for the tooling required to meet both platforms (1.2B in this case when you add both Windows Store and Apple Store ATM), further increasing your bottom line and pleasing those shareholders.

    Everyone wins, RIGHT??? 🙂 🙂 🙂

    • For those interested in the Apple 1B active device news.

      FWIW, I believe in Windows 10 and it should definitely be @ 1B by 2018. It would be nice to be able to say that with ONE code base/tool chain you can reach 2B devices (1B Windows, 1B iOS — there are more platforms, but I am trying to keep to the subject matter here, LOL).

      Finally, on that note, mull on this: imagine if MSFT offers a tech that allows developers to reach 2B users (1B Windows + 1B iOS) in 2018, and Apple only offers tech to only reach 1B users (iOS only), which tech do you think developers (and organizations) are going to gravitate to? Telling you, MSFT: $$$. Make those shareholders happy! 🙂 🙂 🙂

      • Hi Michael DeMond,
        You are saying that while MS is allowing iPhone devs to target Windows also (1B+1B), it is not helping its own developers to target iPhone users. right? But there is already a product called Xamarin which does that, https://xamarin.com – Create native iOS, Android, Windows, and Mac apps in C#. So why re-invent the wheel?

    • Hey Michael – Yes there are developers currently using it and apps in the Windows Store already. If you have built an iOS app and have the ability to reach new users, devices and use a single codebase (so the project is completely portable between platforms), then why not give it a shot?

      • Hi Michael (nice name!), thank you for your reply. You ARE correct…. if you can use one codebase to reach multiple platforms… why not give it a shot?

        However, I hope you realize the terrific irony (more like tragedy) that we as MSFT developers now have to code in ObjectiveC/iOS to do exactly that. Does this make sense to you? Does it not seem like it would make more sense to have a MSFT technology that enabled one codebase (in .NET) to work on both the Windows Store and the Apple store (and Droid store), maximizing our target reach?

        Does it not concern you that MSFT is essentially putting its own developers in lower value tier by catering to another technology? This seems rather suspect and I am surprised that there isn’t more outrage/questioning towards this.

        Again, this “bridge” seems totally backwards. Check my logic, though. I am open to feedback.

        Also, I understand that there might be iOS developers (as in, 2? LOL) using this, but I am wanting to know stats as in how many… and how many of them are doing it because MSFT is paying them to support/develop for a questionable business strategy (ala WinJS). 😛

        • Hey Michael,

          Just wanted to let you know we’re working on bridges that go both ways 🙂


          The goal here is to maximize code reuse for developers of all stripes – whether they’re dealing in C#, Objective-C or web technologies, and whether they’ve started on Windows or another platform – enabling them to build great UWP cross-platform apps with minimal additional investment. Thanks for your interest in the bridges, and remember to reach out on Github if you get a chance to try the iOS bridge with your apps!


        • Hey Michael,

          You don’t have to code in Obj-C to create UWP apps. This is just another path for a new audience. You can use a shared codebase with the Windows Bridge for iOS that works across both the Windows and Apple Store. See the To-Do post here : https://blogs.windows.com/buildingapps/2016/01/20/building-a-simple-app-with-the-windows-bridge-for-ios/. Why do you feel this puts MS devs in a lower tier? They can write their app natively using their language/IDE that they are already used to. I’m sorry but I don’t have any stats to share.

          Take care,

          • Thank you for your reply, Michael.

            There are two things here: writing apps for the sake of technology (your angle/perspective — which I appreciate, I used to be a Silverlight developer, sore topic 😛 ), and then there is writing apps for the sake of market reach and business opportunity.

            Currently there are 200M (probably a little more at this point) Windows 10 installs. There are over 1B active iOS devices as outlined above. Combined, there are 1.2B between them.

            Now, if I want to reach that entire market, which language do I have to use? I can’t use UWP because that only reaches 200M (about 16%). The answer here obviously is iOS/objective-C (100%). Thus, UWP is in the lower (value) tier because it cannot reach the entire market, and I as a business owner now must decide to use iOS/objective-c (higher value) over UWP (lower value) to reach all 1.2B devices.

            Does that make sense? Please let me know if you have any questions around this or if there is something wrong with my logic.

            Also, it would be nice to see the stats. Having transparency with your developers is a valued quality of an organization, and makes it look like you care. Just ask Azure or VSO/VSTS. 🙂

            Thank you,