Sergei Borisov

вариантов несколько:
- Сохранять в репозитории файлы проекта (это худший вариант)
- Импортировать его на другом компе с нуля из исходных текстов, как предложил DevMan (это намного лучше)
- Создать проект на основе какой нибудь ситсемы сборки (если Android, то лучше gradle) и испортировать уже его (это предпочтительный вариант)

Конечно, в нормальной ситуации должен все покупать заказчик.

Но заказчики, зачастую хотели бы отложить эти затраты до самого конца. То есть, типа: вы пока сделайте, а я потом проплачу дев-аккаунт.

Но, если с Андроидом все более или менее ОК, то с iOS все сложнее. Разработчик не может адекватно заниматься разработкой, если у него или заказчика нет дев-аккаунта. Поэтому, простой вариант в таком случае, завести себе свой дев-аккаунт.

Согласен, с @begemot_sun
Но чтобы хотя бы примерно оценить свои желания начните с оценки реального времени (в часах), которое Вы на нее потратили. Разделите, скажем, на 2 или даже на 3 (так как, Вы учились и тратили время на изучение). Возьмите среднюю чистую зп в месяц Android разработчика в Вашем городе. Умножьте эту зп на 1.3, что бы учесть налоги и сборы. Разделите полученную сумму на, примерно 170 (примерное число рабочих часов в месяце). Умножьте Ваши трудозатраты в часах на полученную сумму оплаты в час. Добавьте сюда оценочную стоимость амортизации оборудования, и прочие расходы, которые Вам пришлось понести. Это будет минимальная сумма, которую следует просить за Вашу работу.

Передавать программу, естественно со всеми исходными кодами. А про передачу самого приложения можно почитать, например, здесь: stackoverflow.com/questions/16432408/transfer-exis...

Согласен с @FirstX. C# неплох также и для веб и для серверного ПО вообще.

Но хочу добавить. Серебряной пули нет. Xamarin и C# тоже не являются таковой. Действительно Xamarin позволяет легко реализовывать большой класс приложений. Но не следует думать, что Вы можете с его помощью сделать все, что угодно. В любом случае найдутся задачи, которые на Xamarin или работают существенно медленнее (GUI это, конечно, не касается) или реализуются слишком медленно по сравнению с написанием нативного кода.

Поэтому, я бы на Вашем месте уделил внимание языкам C и/или C++. Это, кстати, полезно и для Java программиста при разработке под Android и тем более для разработчика под iOS.

На мой взгляд, Xamarin из всех мультиплатформенных инструментов самый универсальный. Но все же слишком дорогой.

Density и разрешение экрана свзяно друг с другом не совсем прямо пропорционально.

В Android есть такое правило:
LDPI:MDPI:HDPI:XHDPI:XXHDPI=3:4:6:8:12.

например здесь: stackoverflow.com/questions/6166677/android-screen...
или на developer.android.com

То есть, делать персонажа 100 пикселей для xhdpi - очень плохая идея. Лучше, например, 96 пикселей. Так как 96 без остатка делится 6. А высоту не 80, на 78. Тогда размеры персонажа у Вас будут:
LDPI: 48х39
MDPI: 64х52
HDPI: 96х78
XHDPI: 128x104
XHDPI: 192х156

Отсюда можно легко вычислить в каком разрешении Вам надо рисовать персонажа, чтобы избежать не ркатного масштабирования. Находим наименьшее общее кратное между пропорциями. Это будет 24. И рисуем Ваш объект в разрешении 384х312. Из этого размера Вы легко получаете все рисунки всех необходимых размеров. Лучше сделать скрипт, который, например, при помощи ImageMagick масштабирует Ваш оригинальный рисунок и раскладывает по папкам.

То есть, если Вы хотите поддерживать все 5 разрешений, то все Ваши оригинальные рисунки должны иметь размеры, делящиеся на 24 нацело.

Однако, LDPI можно не рассматривать. Тогда пропорции получаются:
MDPI:HDPI:XHDPI:XXHDPI=2:3:4:6.
И в этом случае, очевидно, что все оригинальные рисунки должны иметь размеры, нацело делящиеся на 12. Кстати, даже если Вы оставите поддержку только HDPI и XHDPI Вам все равно нужен множитель 12, а значит Вы дешево получаете поддержку и MDPI и XXHDPI.

Для iOS все чуточку проще. Смотрите комментарий @Lerg.