Xamarin.Forms - App Store rejection

by Runar Ovesen Hjerpbakk


My new app Personal Trainer Worksheet - Time Tracking for Professional PTs is written using Xamarin.Forms and is currently available on the App Store. It's been a pleasure developing it using the Xamarin tools and I decided to release a iOS version first. However the App Store did not quite agree this time...

Application Loader

While submitting the App using Application Loader, it complained that the API usage info to be sent to Apple was too big, and that the analysis would continue on Apples servers. Okay, I thought and submitted anyway.

Moments later, this mail arrived in my inbox:

We have discovered one or more issues with your recent delivery for "Personal Trainer Worksheet - Time Tracking for Professional PTs". To process your delivery, the following issues must be corrected:

Non-public API usage:

The app references non-public selectors in PersonalTraineriOS: artwork, command, finished, initWithSendPort:receivePort:components:, isContainer, isNegative, playbackProgress, playbackRate, rating, removeTarget:, setArtwork:, setContainer:, setLocalizedTitle:, setPlayable:, setPlaybackProgress:

That was quite a mouthful.

Enable linking for SDK assemblies

The app doesn't use many third party dependencies, so I was quite certain the error was on my part.

The Monotouch linker can remove unused classes from your Xamarin iOS App, thus decreasing its size. The "too big" error message in Application Loader was actually a good hint that the linker had not run.

Sure enough, my project settings were set to Don't link. After changing it to Link SDK assemblies only, the API usage analysis ran successfully and the app was approved.

Enable linking for SDK assemblies.png

I don't know why the non-linked binary was rejected, but this thread on the Xamarin Forums shows that I'm not alone.

(If you liked this, you might enjoy Xamarin.Forms 24 hour TimePicker on iOS.)


No content in Solution Explorer using Visual Studio 2013

by Runar Ovesen Hjerpbakk


After opening Visual Studio 2013 (VS) today, I was greeted with an empty Solution Explorer window. This was strange because I'd opened VS by double clicking my solution-file. My Team Explorer window could not help me either, it just showed:

Page '312e8a59-2712-48a1-863e-0ef4e67961fc' not found.

In my previous VS session I had both connected to my Team Foundation 2013 Server (TFS) and worked on this specific solution. What's going on here?

Empty Solution Explorer
e688f7f31e0961fb2182f5509750ed58.png

The first law of tech support or troubleshooting is to turn the thing off and on again. VS didn't even manage to close properly and teased me with this friendly message:

No exports were found that match the constraint: ContractName Microsoft.Internal.VisualStudio.PlatformUI.ISolutionAttachedCollectionService RequiredTypeIdentity Microsoft.Internal.VisualStudio.PlatformUI.ISolutionAttachedCollectionService  

No exports were found that match the constraint:

ContractName

Microsoft.Internal.VisualStudio.PlatformUI.ISolutionAttachedCollectionService

RequiredTypeIdentity

Microsoft.Internal.VisualStudio.PlatformUI.ISolutionAttachedCollectionService

 

Googling this message produced a Microsoft Connect report with the following suggestion:

This issue is because of a MEF cache corruption. Installing the feedback extension (or installing any extension) will invalidate the cache causing VS to rebuild it.

That tip actually worked! I uninstalled one of the extensions I never use, restarted VS and my solution opened as i should. I even managed to connect to TFS! I don't understand what really caused this issue, but I suspect the error messages could be more helpful if they tried...

(If you liked this, you might enjoy Debugger.Launch() in Services on Windows 8.)


Xamarin.Forms 24 hour TimePicker on iOS

by Runar Ovesen Hjerpbakk


I'm utilizing Xamarin.Forms in my next app to more easily support both iOS, Android and Windows Phone using the (mostly) same code base. It's relatively new however, and some use cases are not yet supported using Xamarin's supplied controls.

The Problem

My problem today was showing a TimePicker using a 24 hour time format, regardless of the users selected locale. The TimePicker normally respects the users preference, but I'm using the control to select a range of time, not a point in time.

TimePicker's Format property only affects the string showing the selected time, not the selection itself.

Forcing 24 hours on iOS

Since my next app will first be released on iOS (naturally), I tackled the problem there first. My solution was to create a custom renderer which forces the underlying UIDatePicker to always use a local with a 24 hour time format. In this case I chose Norwegian, but any 24h locale will do.

 
The picture illustrates what I wanted to accomplish.

The picture illustrates what I wanted to accomplish.

To use the code yourself, just drop the class into your iOS project and use the TimePicker normally in your shared project or PCL.