Краткое изложение того, что я узнал за первый год.
18 ноября 2019 года мое первое приложение для iOS было одобрено обозревателями App Store для загрузки. Мягко говоря, я был на небесах! Я хотел сделать это уже много лет. Я тот, кто влюбился в эту идею, как только я проверил iPhone первого поколения в 2008 году.
Прошел год, так что пришло время оглянуться назад и сравнить, где я был тогда и где я нахожусь сейчас. Этакое вскрытие.
Я определенно узнал несколько вещей за год, о которых хотел бы узнать раньше. И я считаю, что мои уроки могут быть полезны для вас в вашем собственном путешествии.
Если вы читаете это, скорее всего, вы думаете о создании собственного приложения. Стоит ли пойти на это? Могу сказать вам через год - оно того стоит. Это прекрасное путешествие, которое, возможно, изменит вашу жизнь. И если я смогу облегчить вам задачу, поделившись своим опытом, это будет еще лучше.
Прежде чем мы начнем, расскажем немного о самом приложении:
Я люблю баскетбол и болею за местную баскетбольную команду, поэтому я создал приложение для других болельщиков, таких как я, и других жителей города, которым может быть интересно.
Основная цель приложения - повысить осведомленность о команде в моем местном сообществе, поскольку самая большая проблема, с которой борется команда, - это ограниченный маркетинговый бюджет, который приводит к ограниченному распространению среди жителей.
Проверить приложение можно здесь. Примечание: в настоящее время все на польском языке.
- Время на код первой версии: ~ 4 недели
- Написано на Swift 5-иш
- Менее 6000 строк кода
- 15 МБ при загрузке (раньше было намного больше, но Swift тем временем стал намного лучше)
- Используемые фреймворки Apple: Foundation, SwiftUI, Combine, CoreLocation, MapKit
- Использованы внешние пакеты: SwiftSunburstDiagram
- Бэкэнд: построен на WordPress, использует WP REST API для обмена данными JSON с приложением. Основная роль Backend - периодически проверять веб-сайт Польской баскетбольной ассоциации на предмет новых данных и обновлять турнирную таблицу, результаты игр и статистику игроков. Он также проверяет наличие новых видео с официального канала команды YouTube - я использую его в качестве кеша, потому что Google устанавливает ограничение на использование их API, которое я достигну, если бы приложение напрямую запросило YT API.
- Основные характеристики: предстоящие игры, MVP последней игры, сравнение статистики, состав команд, турнирная таблица, расписание игр, фотогалерея, раздел фан-клуба
- Будущие обновления: полное переписывание, виджеты и возможность предсказывать результаты предстоящих игр.
Разберемся с основными вещами, пора заняться уроками:
1. Вам необязательно знать все о Swift.
Мне удалось создать приложение, просто выполнив несколько руководств с сайта RayWenderlich.com (первые бесплатные и несколько других, в основном о работе с сетями и FileManager). Я также прошел Стэнфордский курс по разработке приложений для iPhone CS193p, который нашел на YouTube.
Кроме того, я прочитал документацию на Swift.org и некоторые официальные документы Apple по интересующим меня темам.
Но это все! До того, как я начал, у меня практически не было опыта работы со Swift. И определенно я тогда мало знал об использовании протоколов и дженериков. У меня было только базовое представление о ссылочных типах и типах значений.
Это не помешало мне создать приложение.
2. ОБЯЗАТЕЛЬНО прочтите документацию и при необходимости запомните код.
Вначале я боролся с сетью, чтением и записью файлов и декодированием JSON. Мне было немного чуждо то, как Swift и iOS делают эти вещи.
Чтобы преодолеть это, я изучил документы. Учился, например: перечитывал снова и снова, затем практиковался снова и снова, пока это не стало моей второй натурой. Я давно заметил, что когда мне трудно понять что-то с самого начала, я просто практикуюсь и повторяю это до тех пор, пока это не всплывет в моей памяти. Это позволяет мне думать и размышлять над идеей независимо от того, программирую я в данный момент или нет, что, в свою очередь, позволяет мне обдумать и понять тему.
Вывод: попробуйте практиковаться в том, чего вы не понимаете, пока у вас не будет отрывков в памяти, не просто читайте о кодировании. После недели повторения все станет ясно, и у вас появится новый инструмент, который вы сможете использовать везде, где вам нужно.
3. Если у вас не получается с первого раза, продолжайте, пока не добьетесь успеха.
В последние годы, начиная с 2012 года, я пытался создать несколько приложений для iOS. Тогда я пытался изучить Objective-C. Это был ад. Мой код вызывал ошибки во время выполнения, и мои приложения все время падали.
Несмотря на то, что у меня были предварительные познания в программировании, и в особенности я имел возможность поиграть с различными вариантами сборки, а затем с C, даже это не помогло.
Затем в 2018 году я попытался создать баскетбольное приложение с помощью UIKit. Это тоже было беспорядком. Ничего не синхронизировалось, постоянно что-то пропадало, и мое приложение вылетало. Проектирование пользовательского интерфейса в раскадровках, загрузка и наполнение перьев и xib (или как там их еще называется) - мне определенно не нравилось это делать. Да, и схема с двутавровыми балками… Я хочу об этом забыть.
Каждый раз я останавливался и откладывал проекты на какое-то время. Потом я вернулся к ним через некоторое время и продолжил. А потом был выпущен SwiftUI.
Если вам никогда не приходилось писать код на Objective-C или создавать интерфейсы с помощью UIKit - считайте, что вам повезло.
4. С SwiftUI можно легко и быстро создать приложение для iOS.
Теперь SwiftUI. Мне это очень нравится. Полюбите идею, полюбите шаблон проектирования MVVM и все такое. По сравнению с UIKit для меня это рай против ада. Это также самое важное достижение в разработке iOS, которое позволило мне наконец создать свое первое приложение.
Одна вещь, которую вы должны знать, - это то, что я имею опыт веб-разработки, в частности, WordPress. На самом деле это моя текущая работа.
Больше всего я ненавижу в веб-разработчиках CSS, второй в моем списке - JavaScript.
В отличие от CSS, SwiftUI создает макет с использованием такого простого и разумного набора правил. Никогда еще я не разрабатывал пользовательский интерфейс так быстро и легко.
У меня ушло около 4 недель на то, чтобы написать приложение от отсутствия кода до выпуска в App Store. Не думаю, что у меня получилось бы, если бы SwiftUI не был доступен.
Еще раз считайте, что вам повезло, что у вас есть такой мощный и простой в использовании способ создания красивых интерфейсов.
5. Выберите тему, которая вам нравится, и создайте приложение, которое хотите использовать.
Для своего первого приложения выберите тему, которую вы хорошо знаете и любите. Так вам будет намного проще. Кроме того, вам будет намного легче научиться и закончить процесс. Это потому, что вы будете создавать приложение для себя.
Когда я решил создать свое приложение, у меня не было больших ожиданий относительно возможной базы пользователей. Я живу в маленьком городке с населением 60 тысяч человек. Баскетбольные матчи каждые 2 недели собирают 300–500 человек. Я не знал, у скольких из них есть iPhone. Я ожидал, что 50 будут использовать приложение. Я был неправ. Через год их около 60. Я все еще считаю это успехом - если смотреть на это в контексте обстоятельств, это успех.
Самое главное, все это время я был уверен, что у приложения будет как минимум один выделенный пользователь: я. И это подтолкнуло меня вперед.
6. Узнавайте, а затем проводите исследования UX.
Прежде чем я начал писать код, я потратил много времени на изучение UX-исследования и дизайна. Вы можете проверить некоторые из историй, которые я написал здесь, когда изучал темы. Я считаю, что они принесут вам большую пользу, если у вас нет опыта работы с UX. Пойдите дальше, потратьте время на собственное изучение этой области - это будет иметь большое значение.
На самом деле, поскольку на момент запуска SwiftUI еще не был доступен, я даже не планировал создавать приложение.
Я провел исследование, я задавал много вопросов, я говорил со многими людьми об их баскетбольных интересах. Я опубликовал несколько опросов с помощью Google Docs для сбора данных. Но я не планировал выпускать приложение, учитывая мой предыдущий опыт работы с UIKit и Objective-C.
Я планировал написать тематическое исследование, которое стало бы первым элементом в моем портфолио UX. Тогда я буду искать свою первую UX-работу.
UX-дизайн учит вас подходу, ориентированному на человека. Это заставляет вас поставить себя на место потенциальных пользователей вашего приложения. Это заставляет задуматься о том, что другие люди хотели бы иметь и что принесло бы им пользу. А если вы еще не знаете ответов, он научит вас задавать хорошие вопросы и делать заметки.
А потом вышел SwiftUI. Я все еще не UX-дизайнер и создал приложение. Странно, как все оборачивается в итоге!
7. Сначала просмотрите несколько версий без написания кода.
Прежде чем писать хотя бы одну строчку кода, купите блокнот. Обычный старый бумажный. Возьмите толстый, 200 страниц или около того. И ручка. Я использую тонкие карандаши и несколько цветных фломастеров.
Разделите блокнот на 3 равные части:
- Выводы / исследования / закономерности: это для общего мозгового штурма. Запишите все, что у вас есть, о том, что приложение должно делать, каким вы его себе представляете. Сделайте несколько итераций. Не беспокойтесь о том, чтобы придерживаться первоначальной идеи. Дайте ему время вырасти. Позвольте себе исследовать самые дикие возможности.
- Контент: предназначен для записи фактического содержания и общего копирайтинга.
- UX / UI: это для разработки и экспериментирования с дизайном пользовательского интерфейса, взаимодействиями, каркасами и другими видами рисунков, которые помогут вам представить, как приложение может выглядеть и работать.
Вот моя записная книжка для приложения:
Мое правило - иметь одну записную книжку на каждое приложение.
Основное преимущество заключается в том, что по мере того, как вы работаете над идеей, ваши первоначальные концепции начнутся как полный беспорядок и клубок мыслей и возможностей. По мере того, как вы будете их очищать и перегонять, они будут становиться все более и более ясными и понятными.
Я также предлагаю дождаться 2–3 итераций, прежде чем начинать писать какой-либо код. То есть почти полное переосмысление первоначальной идеи приложения. Это позволяет вашему приложению развиваться и углубляться. Вы можете быть удивлены, насколько приложение, которое вы создаете, отличается от приложения, о котором вы изначально думали.
8. Ограничьте объем и количество функций.
Если вы похожи на меня - один человек, который должен заниматься всем в приложении, начиная с идеи, исследуя UX и проектируя, а затем выполняя приложение в коде, - это большое давление, которое нужно оказать на одного человека.
По необходимости мне пришлось ограничить объем моего приложения несколькими основными функциями. Я думаю, что это тоже в какой-то степени пошло на пользу приложению. Мобильные приложения, как правило, должны быть ограничены по объему и сосредоточены на нескольких основных целях.
Мне также пришлось отказаться от нескольких больших идей, поскольку я не был готов их реализовать на тот момент. Не готов - например, я не знал, как превратить их в код. Это был хороший шаг, поскольку в противном случае мне пришлось бы изо всех сил пытаться завершить эти функции, и это задержало бы завершение приложения до бесконечности - и, возможно, снова сорвало бы весь проект.
Я пошел маленьким и легким, и это окупилось.
9. Потратьте время на поиски вдохновения для дизайна пользовательского интерфейса.
Прежде чем я начал разрабатывать приложение на бумаге, а затем в Adobe XD, я потратил очень много времени на поиск в Google идей для дизайна мобильных приложений в Интернете и поиск вдохновляющих историй здесь, на Medium. Если вы ищете вдохновение для дизайна пользовательского интерфейса, вы можете найти здесь несколько публикаций, и я настоятельно рекомендую ознакомиться с ними:
У меня не было опыта разработки настоящего приложения. Конечно, все мы знаем, как выглядят приложения, и понимаем, как они должны работать, но есть еще много чего, что составляет дизайн приложения.
Прежде чем начать, узнайте немного о дизайн-системах. Это поможет вам сделать ваше приложение единообразным и значительно ускорит процесс, когда вы остановитесь на какой-то единственной идее для пользовательского интерфейса.
10. Используйте TDD с самого начала.
Серьезно, не пропустите. Узнать его. Практикуйте это. Прежде чем приступить к написанию приложения, убедитесь, что TDD - это то, что вы делаете.
Мое приложение крошечное. При загрузке это 15 МБ. В нем менее 6000 строк кода. У него нет ни одного теста.
Чтобы сделать мое приложение хотя бы частично тестируемым, мне было бы проще переписать его с нуля, чем реорганизовать его и добавить тесты.
Почему это так важно?
Добавление функций и обеспечение того, чтобы все по-прежнему работало, на данный момент является огромной проблемой.
Право, не шучу. Даже с учетом того, что мое приложение регулярно используют около 60 человек, добавлять в него что-либо или вносить какие-либо изменения - ужасно сложная задача. Я не уверен, что приложение по-прежнему будет работать. Я не могу быть уверен, что не подвел эту крошечную группу фанатов.
Конечно, я тестирую приложение вручную, прежде чем отправлять обновление в App Store. Но все же - я никогда не был на 100% уверен, что все проверил. Я даже не могу представить, как это будет работать в гораздо более крупном приложении, которым пользуется гораздо больше людей.
TDD, когда все сделано правильно, дает вам кнопку, которая при нажатии сообщит вам, все ли в порядке или нет. Без TDD у вас нет этой кнопки, и это становится вопросом чистой удачи.
Некоторые из вас могут подумать, что TDD занимает много времени, замедляет вас и добавляет ненужную сложность. Да, попробуйте провести рефакторинг кода без него - вы быстро поймете, что такое сложность на самом деле.
Я настоятельно рекомендую посмотреть одно из выступлений Роберта К. Мартина на эту тему. Найдите Роберта Мартина (или дядю Боба) на YouTube или, по крайней мере, просмотрите его потрясающий доклад:
11. Используйте пакеты Swift
Когда я создавал свое приложение, Swift Package Manager был еще не так хорош, как сейчас. Я настоятельно рекомендую вам воспользоваться этой возможностью и разделить код на пакеты для упрощения обслуживания и повторного использования. Позже ты меня за это поблагодаришь.
С помощью Swift Packages легко разделять части вашего приложения и разрабатывать их независимо. У вас может быть отдельный пакет для ядра или модели вашего приложения и пакет для вещей, связанных с пользовательским интерфейсом. Это также поможет вам создать более понятную архитектуру и отделить части приложения друг от друга.
Подумайте об этом: когда у вас есть движок приложения, разработанный как отдельный пакет с четко определенными способами взаимодействия с этим движком (API), насколько легко переключить текущий пользовательский интерфейс и вместо этого подключить что-то другое?
Допустим, вы хотите создать версию приложения для Mac. Сейчас у нас есть Catalyst, но, допустим, вы хотели бы иметь совершенно другой пользовательский интерфейс, когда приложение работает на Mac. Если ваш пользовательский интерфейс - это просто плагин для движка, переключиться на него - почти тривиальная задача!
Кроме того, вы можете разделить свой проект на еще более мелкие части. Во-первых, их намного проще протестировать по отдельности. Также возможно, что вы создадите что-то, что другие тоже захотят использовать - это откроет ваш код, чтобы стать частью движения за открытый исходный код. И вам не нужно делиться всем кодом своего приложения со всеми - только некоторые из пакетов, которые могут быть использованы кем-то еще.
Мое приложение не упаковано. Это единый большой фрагмент кода, который займет много времени, чтобы разделить его на более мелкие части для распространения в качестве открытого исходного кода. Я не рад этому, потому что есть кое-что, чем я хотел бы поделиться.
Я на 100% уверен, что мое следующее приложение будет много использовать диспетчер пакетов и иметь четко определенные зависимости.
Кстати: если вы уже создали пакеты Swift и хотите, чтобы их было легче обнаружить, вот моя история о том, как добавить их в неофициальный индекс пакетов Swift (это отличная поисковая система, созданная разработчиками для разработчиков):
12. Вы можете начать с негибкого внутреннего API.
Одна из уступок, на которую я пошел, заключалась в том, чтобы создать бэкэнд в максимально простой форме. Я не планировал делать его гибким - вначале я просто хотел, чтобы он работал и позволял получать данные, необходимые моему приложению.
Бэкэнд - это веб-сайт WordPress с некоторыми настраиваемыми типами сообщений. WordPress имеет встроенную поддержку REST API в настоящее время, поэтому легко получить данные публикации в форме JSON. Также тривиально расширить этот API для отправки дополнительных метаданных.
Недостатком этого подхода является то, что имеющийся у меня API связан с самим приложением. Я не могу делать запросы, чтобы получить из него другие данные. Это очень жесткая конструкция.
Но это сработало хорошо и позволило приложению обновлять и отображать командное положение, результаты игр и статистику игроков - это то, что действительно нужно приложению на тот момент. Он много думал о том, как работают API - из негибкости, которую я узнал о гибкости!
В конце концов, это позволило мне создать надежный, но довольно надежный бэкэнд для моего приложения, не слишком затягивая процесс разработки.
Урок здесь: когда вы только начинаете, не увеличивайте сложность сразу, если она вам сейчас не нужна.
13. Не беспокойтесь о том, что все сделаете правильно с первого раза.
Если вы планируете создать свое первое приложение, скорее всего, оно будет не лучшим с точки зрения качества кода.
Я знаю, что у меня нет. Честно говоря, я не хочу никому показывать код. Но вот как вы учитесь: делая ошибки.
Мой код противоречит всем возможным стандартам и практикам. Я узнал о стандартах и практиках, а также о том, почему они существуют.
Мой код - это полный беспорядок, и иногда мне кажется, что сам факт работы приложения - это чудо. Теперь я знаю гораздо больше и знаю, какие ошибки совершил, чтобы в следующий раз их избежать.
Все это помешало мне создать приложение? Неа.
14. Ваше первое готовое приложение породит больше идей для приложений.
Как только я разместил свое приложение в App Store и период празднования закончился, я начал получать все больше и больше идей для приложений, чем когда-либо раньше. В какой-то момент мне пришлось создать новый проект в Todoist (мое любимое приложение для отслеживания задач), чтобы записать их все.
Определенно займитесь отслеживанием задач, если знаете, что у вас бывают похожие творческие приступы. Наличие места, где вы можете записывать и хранить свои идеи, даст вам два преимущества:
- вы освободите свой разум: когда наш мозг думает, что что-то важно, он будет использовать энергию, чтобы эта мысль оставалась доступной для нас, пока мы что-то с ней не сделаем. Эта мысль зациклится в наших головах и утомит нас. Когда мы записываем идею туда, где, как полагает наш мозг, мы вернемся к ней, он сможет отпустить и передать долгосрочное хранение идеи внешнему инструменту.
- вы сможете развить идею по мере появления новых мыслей: и поверьте мне, они будут. Так начинаются все мои идеи приложений. Сначала я оставляю их в приложении, добавляю подзадачи и комментарии, пока не начну замечать, что там есть что-то интересное, и перенесу идею в блокнот для дальнейшего исследования.
Вот почему я предлагаю сначала создать небольшое специализированное приложение и позволить вашему творчеству продвинуться дальше. Я использую этот подход во всем, что начинаю. Даже когда я пишу здесь, на Medium, я публикую разные сообщения, проверяю разные идеи и узнаю, что сработало, а что нет. Я не сразу иду ва-банк.
15. Полная перезапись может потребоваться раньше, чем вы думаете.
Это абсолютно нормально. По мере продвижения и изучения исходного кода вы начнете замечать, что для некоторых улучшений будет проще фактически переписать код с нуля, чем пытаться улучшать его по частям.
Это верно, особенно если вы пропустили TDD и хотели бы добавить тесты в последнюю очередь.
Это также связано с тем, что со временем вы начнете замечать возможности для улучшения общего UX вашего приложения. Теперь я понимаю, что, например, я мог бы оформить домашний экран совершенно по-другому. Я также мог бы придумать гораздо лучшую информационную архитектуру для приложения.
Это неизбежно, и вы не должны беспокоиться об этом, начиная свой проект. Просто имейте в виду, что наступит время - и это произойдет раньше, чем вы думаете, - что вы будете работать над версией своего приложения 2.0. Спланируйте это и составьте график.
16. Внешние источники данных меняются и могут нарушить работу вашего приложения.
Несколько месяцев назад веб-сайт, который я использовал для получения данных для своего приложения, был переработан и перемещен в другой домен. Это застало меня врасплох, и на какое-то время мое приложение перестало обновляться. Хорошо, что это было в межсезонье. Чтобы учесть это, мне пришлось переписать функции сбора данных в моем бэкэнде.
Если бы это произошло в течение сезона, я бы, вероятно, пропустил этот факт из-за отсутствия каких-либо уведомлений в случае таких сбоев.
Сеть - самая сложная часть моего приложения. Сеть также, как правило, является самой ненадежной частью любого программного обеспечения - здесь велика вероятность того, что что-то пойдет не так, поэтому нужно приложить много усилий, чтобы сделать эту часть как можно более надежной и устойчивой к ошибкам.
В следующий раз, когда я создам приложение, использующее сеть, мне придется выделить гораздо больше времени на создание этой части кода.
17. Выделите время на обслуживание и постоянную поддержку.
Вещи сломаются. Вещи перестанут работать. Будут баги.
Легко потерять себя в процессе творчества и забыть об этом. И вы действительно можете сделать это изначально, и это нормально.
Но имейте план поддержки приложения, который включает в себя не только добавление дополнительных функций по ходу работы. Выделите дополнительное время для поддержки, взаимодействия с пользователями и устранения проблем.
Даже если ваше приложение не требует значительного обслуживания после выпуска, было бы лучше, если бы вы разработали план, чтобы проверять приложение хотя бы раз в неделю и убедиться, что оно работает нормально. Убедитесь, что у вас есть свободное время, чтобы заняться этим, поскольку жизнь обычно мешает.
18. Не сравнивайте свои обычные дни с лучшими.
Вы неизбежно вначале полностью погрузитесь в создание приложения. Хорошо.
Но я заметил, что после того, как приложение было готово, у меня было несколько дней, когда я сравнивал их с прошлыми, и сравнение выглядело не очень хорошо. Я не делал так много, я тратил гораздо больше времени на кодирование, чем раньше, с небольшими достижениями. Я не доработал новую функцию вовремя, и мне пришлось потратить дополнительные дни на ее внедрение.
Проблема в том, что мы не должны пытаться поддерживать такой стабильно высокий результат, и первые дни разработки никогда не должны становиться ориентиром, по которому мы себя измеряем. Это негативно скажется на вашем здоровье и принесет больше разочарований, чем прибыли.
По окончании начального периода кодирования сделайте себе одолжение и установите более реалистичную основу. На самом деле, сделайте свою работу разработчика немного скучнее. Сдавите взлеты и падения. Это позволит вам больше ценить свою работу и получать от нее удовольствие.
По окончании начального периода стремитесь к стабильному и стабильному результату.
19. Вы будете завалены просьбами сделать версию для Android.
Это забавно для меня. Мое приложение предназначено только для iOS, и я никогда не планировал, что оно будет доступно для других платформ, таких как Android.
Но с самого начала люди начали заваливать меня более или менее неприятными сообщениями, спрашивая, когда выйдет версия Android.
Не если - когда.
Если вы создадите для одной платформы, пользователи других платформ, естественно, будут завидовать людям, у которых есть доступ к вашему приложению. И они будут приходить к вам с вопросами.
И наступит время, когда вам нужно будет решить, пойдете ли вы с этим или нет. Конечно, это будет зависеть от вашего приложения.
В течение года я давал разные ответы людям, которые связались со мной по поводу версии Android. Однажды я сказал да, я создам его. Затем мне пришлось сказать нет, когда я погрузился в Kotlin, а затем в Flutter.
Что я могу вам сказать, так это то, что по сравнению со Swift и Xcode инструменты и языки, используемые для разработки под Android, не доставляли мне удовольствия. Особенно Flutter, который заставляет вас увлекаться материальным дизайном, который мне совсем не нравится.
Одна из причин, по которой мне не нравится материальный дизайн, заключается в том, что мне приходится каждый день пользоваться инструментами Google в своей повседневной работе. Каждый раз, когда я захожу на любую консоль Google, меня встречает огромная стена текста. Я должен внимательно прочитать большую часть этого, чтобы понять, куда мне нужно двигаться дальше. Огромное количество текста и отсутствие четкой фокусировки увеличивают нагрузку на пользователей. Если вы спросите меня, это плохой UX.
Я понял, что хорошо спланировать это заранее и с самого начала дать понять, собираетесь ли вы это делать или нет. Я не планирую создавать какие-либо приложения для Android, в данный момент я бы предпочел нанять кого-нибудь, кто сделает это за меня.
20. Вы захотите бросить свою повседневную работу и заниматься этим всю оставшуюся жизнь.
Это лучшая часть!
Создание приложения - это настолько увлекательный опыт, что, начав с него, очень сложно не подумать о том, чтобы полностью изменить свою карьеру или, если это то, что вы хотели делать с самого начала, - продолжить более уверенно на своем пути.
Я мало что знаю о других платформах, но в случае с Apple это открывает прекрасную возможность для всех, кто любит программировать и заботится о какой-то конкретной идее или проблеме. Если вы обнаружите, что можете смешать и то, и другое, ничего лучше не будет.
И с каждым годом он становится все лучше и лучше, поскольку Apple стремится превратить все свои аппаратные продукты в единую платформу, где вы можете один раз создать приложение и запустить его на iPhone, iPad и macOS, не меняя ничего в коде. Это, мягко говоря, потрясающе.
Я боролся с мыслью полностью переключиться, чтобы стать разработчиком приложений. Чтобы открыть собственную студию и создать больше приложений. Чтобы зарабатывать на жизнь этим. Я все еще думаю об этом, так что кто знает, что нас ждет в будущем.
Как видите, я выбрал много ярлыков. Некоторые из них быстро отвернулись от меня. Все в порядке. До этого я не знал, что вы можете воспользоваться этими ярлыками, и не знал, что их использование - плохая идея. Мое следующее приложение, над которым я работаю, кажется намного лучше с точки зрения разработки и качества кода из-за уроков, которые я усвоил.
Меня бы здесь не было без ошибок, которые я совершил.
Я также не был бы так доволен по сей день, что смог создать приложение, которое работает и используется людьми, которым оно нравится.
В общем, кажется, что это фантастический путь для следования.
И если вы стоите на пороге своего дома и думаете о том, чтобы сделать первый шаг вперед, сделайте это. Я желаю вам столь же удачного путешествия, как и я до сих пор. Я надеюсь, что мой рассказ также пролил свет на вас и показал несколько вещей, которые можно использовать в вашей практике программирования.
да. Действуй. Учиться. Итерировать. Улучшать. И наслаждаться!
