I know that a couple of months ago I said that Burst-a-Bubble would be my last project written with 2dToolkit and instead I'd be using Unity's native 2D. In the mean time I've made a start on that idea and I really have to say that I have to reconsider that thought for performance reasons. A performance that most certainly will be inflicted on mobile platforms, but also on PC systems (Windows, Mac and Linux).
Above is a screenshot made in the Unity editor using it's native 2D support and below is one made with 2dToolkit. I have enabled the wireframe for the 2D sprites and I've selected the active camera. As you can see there are 2 very significant differences between Unity's native 2D and 2dToolkit when it comes to both the displaying of sprites and using the camera.
As you can see from the wireframes, Unity's native 2D support east up a lot of performance on the screen. To make things even worst, all 3D settings also apply to the 2D game created this way. This means you have to manually override them in the settings but still the performance is not optimal then. Then try to imagine this worse performance on an Android (or iOS) machine that's a lot lower-end than most PCs and you can expect some lag to appear when you drop a lot of sprites on the screen.
Then the 2dToolkit wireframes. These are simple and display the as you've made it. You can still apply all those 3D settings to the game on a PC platform, but it doesn't affect the performance at all! Then playing the game on Android, this does totally not affect the performance at all. I have 2 phones (a Motorola Moto G 4G and a LG L5II, of which the LG is clearly a low-end phone) and the game plays smoothly on both of them.
When looking at the camera of both Unity's native 2D and 2dToolkit, the latter one clearly is superior. You can define your resolution as you want it to appear, while for Unity's native 2D you only can set (half) the pixels vertically (WHY?). When not in the predefined resolution will be scaled.
For Unity's native 2D it'll hold on to the set (half) vertical pixels and it scales on the horisontal axis. This means that calculating locations of sprites will become a real pain in the ass.
For 2dToolkit things stay very easy. First off you can tell how the camera will respond to other resolutions. You can set it to stretch, keep either horisontal or vertical axis as 'leading' scale or a couple of other settings I've never used before. Then dispite of the actual resolution, the main screen will keep it's regular resolution. This means in the above example where resolution is set to 1280x720 and the player will take an 800x600 resolution, the visual area of the game will still be seen as 1280x720 for displaying sprites. Anything outside that resolution is either negative (when below the pre-set resolution) or over 720px (when above the pre-set resolution). This makes screen editing a lot easier than Unity's native 2D!
Of course, there are a couple of uncertainties for me as of now. I want to use skeletal animated sprites created with either Spriter Pro or Spine. I fear then using Spriter Pro, the native Unity 2D wireframes will kick in because of how it's handling the sprites. For Spine I'm not sure though. I know it makes an atlas file like 2dToolkit does, but I have yet to make a skeletal animation and test how it responds. My guess (and hope) is that it'll not use the Unity native 2D wireframe but instead use it's own (better?) system...
[UPDATE] I've tested Spine and as expected it's using the same wireframe as 2dToolkit does. This means that eventhough Spine is a very powerful animator, it's taking minimal performance when displaying the sprites within the animations. Not sure though how much the animations will eat in performance, but I guess it won't be that bad though...