Notes on Cisco’s Meraki Systems Manager as an MDM Solution

A few of the devs on my team recently got a chance to try out the free version of Meraki’s Systems Manager. In this case, I’m using MDM as an acronym for Mobile Device Management. We used the system on and off for most of 2015 to distribute some apps published using an enterprise provisioning profile for iOS.

Use cases

Our usual scenario involved a series of iPads, often 10 – 30 of them. They would be sent out to an event space on a convention floor, a mall booth, an outdoor event space (like Six Flags). Sometimes the devices would be used for user registration, running on a local network inside a stadium. One project involved a bunch set up outside a traveling food truck, that drove from town to town. A few projects required sweeps registration or mailing list sign up of some sort. One large project involved multiple Elo Touch Screens that ran Windows Pro and traveled between mostly outdoor events. Since most of our events involved using Meraki with a series of iPads, I’ll use the .ipa app upload process as the example going forward.

Overall impression

Overall, if your app is under 30MB in file size, Meraki is a great solution. Just set up your account, go to

• Systems Manager > MDM > Apps
• select “Add New” in the upper right corner of the page and “iOS enterprise app” from the dropdown.
• Under Location, choose “Upload an ipa” from the dropdown and follow the given options, as needed. Click Save Changes and you’re set.
• Add devices (Systems manager > MDM > add devices) and use tags to automatically install your app on the appropriate device
• Once the app’s live and installed, you can update using the same App page (Systems Manager > MDM > Apps, click your app name)

Some issues we came up against

• The Meraki dashboard doesn’t seem to allow you to search “Clients” (Systems manager > Monitor > Clients, what the system calls the devices you’ve registered) by convenient terms like serial number or device name. Sometimes I have a lot of devices with a given tag and I need to make sure a specific device is in that list. Being able to search by device serial number would save me time.
• Enterprise apps larger than 30MB in size are often problematic to update. It often took multiple attempts over a few days to get the update to work, even after on-site connectivity was good for other purposes, such as playing back a streaming video off of sites like CNN.com.
• On-site firewall at YMCA branches (using YMCA WiFi) were blocking remote app updates.
• Spotty venue WiFi (read: convention floor WiFi) and sometimes spotty MiFi connections are an issue if your app requires an update or needs to send more than just text data. App updates for apps bigger than a few MB, required taking the device to another location with strong, consistent WiFi.
• When you’re stuck on an issue, such as an app just won’t install, no matter what you do, there’s not much google-able info out there. Stackoverflow is very helpful to keep you moving, past bugs and roadblocks, but not with the free version of Meraki’s System’s Manager. We haven’t yet had the need to contact Meraki support (given our previous experience with trying to reach out to support with free products, we pursued the issues on our own, so far successfully).

Some conclusions

I’d highly recommend Meraki for smaller sized apps, especially ones that are not likely to require an app update during your short term event’s duration. For longer term installations, larger apps, be prepared to budget for and plan for on-site travel for one of your developers, technologists or IT guys to help with initial installs or especially problematic app updates.

This has less to do with MDM, and more with network connectivity, but your MDM will largely depend on how good your connection is. Seriously consider / advise your client to purchase a data plan for the device, rather than relying on WiFi alone. Find out ahead of time, which mobile service has a reputation for working best in your target location. Don’t use Verizon, if AT&T is generally known to have better service in your event’s target area. If your devices are PCs, by all means, run hard lines (Ethernet) and bypass wireless issues all together. Just keep in mind, the longer those Ethernet cables, the lower the signal tends to be.

Unity3D for iOS: Setting Up a New Project and Deploying for QA with TestFlight

NOTE: This post is definitely in the Notes to Self category. Not sure how useful this may be to anyone I’m not directly working with.

Apple Developer Center

There are plenty of free tutorials on how to do this but here’re the steps:

1. [First time only] Set up Apple Developer Account & Create your personal Certificate in .p12 format.
2. Create an App ID
3. add Device IDs if needed
4. Create Dev Provisioning Profile & download it to your machine.

Set Up Unity Project for iOS

1. Create a New Project & go to File > Build Settings > Player Settings
2. Fill in Company Name & Product Name (the app name you picked in Apple Dev Center when setting up the App ID).
3. In Player Settings, under Per-Platform Settings in Other Settings set Bundle Identifier* to the App ID you created in the Apple Developer Center (something like “com.yourcompany.yourAppName”)
4. Other Player Settings seem fairly self-explanatory if you’ve done iOS dev before

Import Your Assets, Copy/Paste Items

1. Imported your team mate’s game scene(s) from their latest .unitypackage.
2. Imported MainMenu & endGame scenes, import level1 and level2 for reference from Cubesteroids3 (or latest).
3. Add any GameManager or GameSettings objects & their related scripts to the Hierarchy in the imported scene.
4. Add UIToolkit’s UI object to imported scene. Notice, it’s UILayer setting in Inspector will probably be unset. If you don’t feel like updating this every time – turn UI and it’s children into a Prefab, which will retain layer settings for you.
5. If a Layer named UIToolkit doesn’t exist – name User Layer 10 (or one of your choice) “UIToolkit”. Click on UI in the Hierarchy, in the Inspector the UILayer setting should now be set to UIToolkit.
6. Select “UIToolkit – text” in Hierarchy, in the Inspector the Layer should be set to UIToolkit. If not, manually set the Layer to “UIToolkit” in the Inspector.
7. Merge ui / gui code from the old [GameManager class called] ThrowRigidBody.js to the new ThrowRigidBody.js. Without a “Team License” from Unity Technologies, this is a manual, line-by-line process unfortunately.

Prior to Build & Run

1. Download your Dev Provisioning Profile
2. If it’s an official release, make sure you’ve switched the Dev Provisioning profile from a test one to one using your Team’s Apple account
3. Open Xcode. Do Window > Organizer.
4. Drag your Dev Provisioning Profile into your list of profiles in Organizer. Connect your Device – you might need to drag a copy of the Profile to your device’s Provisioning Profiles tab in Organizer
5. Hit Build & Run in Unity… should work.

To Distribute Wirelessly via TestFlight

1. Set up an account at TestFlightApp.com, if you don’t already have one OR ask to be added as a Developer to an existing Team account.
2. Open the Xcode project generated by Unity when you Build & Run
3. Create an Archive in Xcode. When the Archive is read, click the SHARE button in the upper right corner of the IDE. Choose the appropriate Dev Provisioning Profile (there can be several in the list if this isn’t your first iOS project). Choose where to save the .ipa. If this part is confusing – a quick Google search will help w/ sources like Stackoverflow.
4. Drag the .ipa into TestFlightApp.com’s Upload page.
5. Follow TestFlight’s link to Invite Testers. NOTE: After new testers register their devices you might have to add them to your Dev Provisioning Profile via Apple’s Dev Center, recompile your app w/ the new profile & reupload your .ipa. Not sure if TestFlight has found a faster workaround to this.

To Quickly Allow a New TestFlight User to Install Your Build

1. Send them a Tester invite via TestFlight. After they register their device, grab the Device ID.
2. Add Device ID to your/your team’s Apple Developer Account
3. Add the newly added Device to a Dev Provisioning Profile for your App ID
4. Download your new/updated Dev Provisioning Profile to your machine
5. On TestFlightApp.com go to Builds > Your Latest Build, choose Permissions in the left nav.
6. Click on the UPDATE PROFILE button under Update Provisioning Profile to upload the new Dev Provisioning Profile that includes the new Tester’s device ID. This step allows you to skip re-compiling your app just to add dev install permissions for a new device.
7. Notify your new Tester.

Notes on Managing a Flash Dev Team

This is a basic check list of stuff a Manager of a Flash Developer team needs to know/do. Hopefully, this could be helpful  to anyone who manages other Front End, Rich Media or similar user interface-oriented Developer teams.

For the purposes of this article, a Manager is the person who has a bunch of Flash Developers reporting to her and the Department Head calls you when stuff breaks, when clients have a sudden heart attack over something they forgot needed to go live yesterday, etc. Ideally, you’re also the person to whom Project Managers come before they assign any work to any Flash Developer on your team. Even more ideal (or idealistic? =) ), you’re the person Creative comes to for feasibility assessment/feedback before they design stuff to work a certain way (or not) and before they sell it to Clients or other departments.

Managing digital assets / source files

• have a weekly check in w/ your team regarding the latest source files for each of their projects
• use SVN for deployment files (SWF, xml, images, videos that users/clients/customers see as part of the end product)
• enforce either a very organized folder naming & creation convention or something like Adobe’s Version Cue for all team coding/production assets
• try to negotiate a .PSD delivery protocol w/the Creative team so that PSD Layers/ folders are clearly labeled
• in return for the above try to give Creative as much as possible of what they want when it comes to functionality, animation, bells & whistles, etc (within possible tech specs)

Managing the Project Managers

• if you don’t, your team will be easily overwhelmed with projects, some will be working light, while others are slammed all the time
• while fire drills are sometimes unavoidable, try to stick to allocated t
• it’s not always the PM’s fault — they get evaluated based on how quickly they get others to get their projects done and yet they themselves can’t do the actual work
• a PM once told me: “once we find a developer who’s good, we try to get them to do all of our projects” — while understandable,  this can leave certain people on your team overworked on a regular basis, which may cause talent retention problems, to say the  least.
• try to negotiate a workflow with the PM’s where all of your team members’ hours get assigned through you – this will reduce the impact of the the above
• have a weekly allocations meeting with all PM’s – this way they each know what the other is trying to get your limited crew to do and priorities can be set/negotiated – note, your developers don’t need to be at this meeting, let them do the actual work, while you handle this planning part

Vacation Planning for Flash Dev team Managers

• really tough to plan time-wise (in many cases, you end up having to be reachable by phone or email, even on vacation)
• make sure the person filling in for you has: all your logins/passwords (write ’em on paper, to avoid emailing/IM’ing sensitive data)
• find out if anything is launching while you’re away – get related work done before you leave / at least write detailed instructions
• make sure all potential source files for everything are up to date and can be easily found by others

Managing your boss

• try to keep current on all projects handled by your team for that one time you get a late night or weekend call asking you “what’s going on with XYZ?”
• understandably,  the above can be tough, especially, when your entire life seems to revolve around going to meetings
• try to fit in a weekly status meeting w/ your team – try doing at least an occasional code review, so that the junior guys can learn from the senior guys

When to step in

• if the process falls off the rails – for example, PM’s allow Creative to make 20 rounds of changes after development has already started. It’s reasonable to expect Creative feedback but at some point things just have to get done and the PM needs to either set a cut off point for feedback or change the project time line.

To be continued / appended / edited as time permits…

Most of the time Developers have to work late, not because of the work itself  but due to insufficient or incorrect planning and workflow organization within the company or team. While there are always times when working 24-7 is important for a Developer (when learning a new language or debugging a particularly stubborn app originally written by someone else), most people want to and are able to get their work done well, on time and without having to live at your desk like a one-dimensional drone.

This is mainly a quick check list for myself, but any constructive comments, suggestions or shared experiences are totally welcome, just use the comments section below.