Об ужасной документации Apple

Автор оригинала: Casey Liss
  • Перевод


В последние год-два я пришёл к осознанию того, что основной преградой к выполнению моей работы является документация. Или, если конкретнее, откровенный дефицит документации, предоставляемой Apple для своих платформ.

Apple предоставляет разработчикам набор инструментов — API, позволяющий нам создавать приложения для iOS, iPadOS, macOS и tvOS. Во многих случаях разобраться в том, как пользоваться этими API, достаточно просто. Как отвёртку можно использовать очень немногими способами, так и во многих случаях есть только один очевидный способ применения API.

Однако, в то время, как пользователи справедливо требуют всё более сложных и изощрённых приложений, API тоже часто должны становиться всё более изощрёнными и сложными. Внезапно оказывается, что кроме простых отвёрток и молотков у тебя уже появляется электроинструмент и сложные пилы, и всё оказывается намного более хлопотным, чем было раньше.

Когда покупаешь настоящие инструменты, то ожидаешь получить с ними и руководство пользователя, описывающее способ применения только что купленного инструмента. Приблизительная аналогия в некоторой степени существует и для API — большинство владельцев платформ предоставляют документацию. По сути, это «руководство пользователя» API.

В течение многих лет документация Apple была довольно плохой. За последнюю пару лет она прошла этапы «плохая → ужасная → отвратительная → постыдная». Слишком уж часто бывает, что при изучении того, как делать что-то новое и пользоваться незнакомым мне API, меня загоняют в тупик эти три пугающих слова:

No overview available.

Таким образом Apple говорит: «Пошёл ты, разбирайся сам».

Ситуация с No overview available настолько плоха, что популярный ресурс по Apple (который сам по себе, наверно, и не нужен был бы в идеальной ситуации), использовал это словосочетание в качестве названия сайта, подчёркивающего, насколько плоха документация Apple.

Движение прогресса вперёд не улучшает ситуацию. Как указал мне в Твиттере мой друг Адам Суинден после устаревания одних API в новые иногда и не думают добавлять документацию. Оцените разницу между этим API и пришедшим ему на замену.

«No overview available». Пошёл ты, разбирайся сам.

Пару лет назад появились два потрясающих API, связанных с UICollectionView:


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

В недавнем подкасте сайта Under the Radar мои приятели Марко и Дэйв продолжили тему перехода Марко на Swift и SwiftUI. В этом эпизоде Марко и Дэйв весьма красноречиво описали ужасающие мучения, которым подвергаются разработчики Apple, пытаясь понять, как пользоваться предоставленными Apple инструментами. В конце поста есть транскрипция подкаста, немного подредактированная для удобства чтения.

Я несколько лет бил в этот барабан. Я понятия не имел, в чём проблема на стороне Apple.

  • Отделу документации не дают времени, чтобы отреагировать на новые API? (Я бы в это поверил.)
  • Документация не считается обязательным требованием для выпуска API? (Я бы определённо в это поверил.)
  • Отдел документации плохо справляется со своей работой? (В этом я сомневаюсь.)
  • Отдел документации слишком мал? (Скорее всего.)
  • Отделу документации мешают политика и конфликты? (Вероятно.)

В чём бы ни была проблема, её нужно решать. Проблема усугубляется уже несколько лет, и чаша терпения наконец переполнилась.

Транскрипт подкаста Under the Radar


Marco: если изучаешь SwiftUI, то в первую очередь узнаёшь, что существующие обучающие ресурсы довольно ужасны, потому что это очень молодой язык/фреймворк/да и просто образ восприятия вещей. Он настолько молод и так часто меняется (как Swift в своей молодости), что многие туториалы, примеры кода и ответы на Stack Overflow уже просто перестали быть верными. Просто потому, что всё изменилось по сравнению с предыдущим годом. Или потому, что ответ был дан по бете, а в более поздней бете, выпущенной в том же году, изменилось название класса или способ выполнения им какой-то функции.

Сейчас очень ощущается большая потребность поддержки документацией со стороны Apple. Одна из отличных черт PHP в том, что он всегда имел превосходную документацию на своём веб-сайте.

На php.net можно найти любую функцию, а в редакторах добавлены горячие клавиши, поэтому, например, в Textmate я могу нажать ⌃H и появится окно с документацией с сайта php.net о той функции, на которую сейчас установлен мой курсор. У этого языка всегда была отличная документация. На страницах документации по каждой функции языка, а их много, были фрагменты примеров кода. И там есть комментарии! Поэтому даже если пример кода не совсем вам подходит или не отвечает на ваш вопрос, то обычно это делают комментарии.

Именно этого я бы хотел от документации Apple — этих небольших примеров применения, потому что они действительно помогают объяснять, как что-то делается или для чего нужна функция.

Когда мы начали перемещаться на территорию SwiftUI и Combine, а также всех этих высокоуровневых концепций, всё это постепенно становится сложнее — то же самое будет справедливо и когда в Swift реализуют async/await, предположительно через год-два. Становится сложнее понимать многие такие концепции, потому что они очень абстрактны и имеют очень простые названия, по которым трудно сказать, что они делают и как ими пользоваться. Поэтому всем нам приходится отправляться на StackOverflow и в блоги с туториалами, потому что собственная документация (даже если она хотя бы есть, это уже большое событие) настолько лаконична и минималистична, как будто её спроектировал Джон Айв [известный дизайнер-минималист].

Дэйв: … это как большая белая комната…

Марк: Да, это большая белая пустая страница. На ней написано «этот тип нужен вот для этой конкретной вещи», после чего нет никакого контекста; нет примеров, показывающих когда нужно его использовать, как его использовать, нужно ли вызывать его определённым образом, как конструктор.

Эти небольшие фрагменты кода на страницах документации могли бы иметь огромную ценность, как это бывает в случае PHP. Например, «вот пример из четырёх строк того, как использовать эту штуку». И когда я всё это изучаю, мне так не хватает подобного.

Я могу представить, что начинающие так воспринимают почти все элементы программирования; поскольку я такой же новичок в Swift и SwiftUI и во всех концепциях, на которых построен SwiftUI, я впервые за долгое время ощущаю, каково быть начинающим. Мне бы очень пригодилась более качественная документация, я бы выиграл от того, чтобы кто-то (вероятно, Apple) приложил много усилий не только к написанию документации, но и к её обновлению в процессе изменения языка.

Эта проблема возникает, когда молодые языки или фреймворки активно развиваются. Если ты учишься по туториалам в блогах и ответам в StackOverflow, то все они довольно быстро устаревают, как я говорил ранее. Никто в Apple не занимается на полную ставку тем, чтобы все эти туториалы в блогах обновлялись при изменении языка, поэтому чаще всего они не обновлятся. Или некоторые обновляются, некоторые нет, поэтому сложно понять, с чем ты столкнулся.

Но даже в такой ситуации, когда SwiftUI привлёк к себе за последний год такое внимание фанатов языка, по нему всё равно очень мало материалов. Ещё меньше материалов о чём-то более глубоком, чем тривиальные примеры использования. Например, если тебе нужно сделать техническое демо на SwiftUI, в котором должна быть кнопка с изменяющимся состоянием или инкременты числа, то замечательно! О подобном существует миллион постов.

Но рано или поздно у тебя возникает вопрос: «Ладно, а как связать это с остальной частью приложения?» Это настоящее приложение, имеющее реальные потребности в постоянном хранении данных, различных экранах и тому подобном. Как только ты добавляешь сложность реальных приложений, в большинстве подобных туториалов она не рассматривается. Дэйв, однажды мне нужно было адаптировать SwiftUI из этих тривиальных туториалов и выступлений Apple на WWDC к ответам на вопросы «Как мне подключить это к своей базе данных?», «Как подключить это к моей системе скачивания файлов или движку синхронизации?» И таких вопросов было много. Мне кажется, в конечном итоге я с этим разобрался, но, чёрт, всё это нетривиально и неочевидно, к тому же есть множество странных небольших тонкостей.

Дэйв: Я полностью разделяю твою боль. Меня так расстраивает то, что онлайн существует всего пара действительно замечательных ресурсов по SwiftUI. Для меня это Hacking with Swift Пола Хадсона. Примерно 80% моих знаний о SwiftUI взято с его сайта и его видео. Он организовал отличный процесс обучения: видео, в которых показывается один уровень глубже тривиального примера, после которого твои знания становятся тривиальными «плюс немного». Это неполный пример, в нём всё равно много шероховатостей, о которых ты говорил. Я уверен, что продолжу сталкиваться с такими проблемами: ты хочешь сделать что-то чуть большее, чем самое очевидное, но внезапно оказывается, что ты падаешь с обрыва, и остаётся только пожелать себе удачи.

Помню, как в начале весны встретил пару людей, занимающихся обучением в сообществе Apple. Это те люди, которые много выступают на конференциях, проводят воркшопы, и так далее. Они говорили: «Знаете что? Похоже, весь 2020 год мы не сможем ездить на конференции, мы не сможем делать многое. Эй, Apple, в нашем сообществе есть множество очень талантливых преподавателей с кучей свободного времени. Было бы здорово, если бы ты этим воспользовалась».

Печально, что уже почти конец года, а компания, похоже, так этим и не воспользовалась. Непохоже, что она сделала какие-то шаги в этом направлении, чтобы использовать всех этих людей, отлично умеющих объяснять материал и создавать примеры приложений, в том, чтобы проделать эту работу, которая могла бы помочь людям в твоём и моём окружении. Я по-настоящему сочувствую тем, кто приходит в SwiftUI без десятков лет опыта программирования. Если это первое приложение, которое вы изучаете, то в некотором смысле оно довольно лёгкое. Очень примитивное приложение SwiftUI на самом деле проще собрать, наверно, проще, чем большинство примитивных приложений UIKit. Но как только вы начинаете делать что-то большее, всё мгновенно становится очень сложным.

Я также думаю о том, что лучше всего для создания документации подойдут люди, которые создают платформу, но в случае с документацией это сделать сложно. Они могут работать над документацией, чтобы она была доступной в процессе выпуска технологий. Я сочувствую всем, кто обучает разработчиков платформ Apple — когда появляется новый SDK или выпускается новая бета, им приходится не спать по три дня, пытаясь суматошно обновлять все свои материалы и раскрывать возможности новых функций. Они выполняют отличную работу, и я ценю её, но суматохи в ней быть не должно.

Можно было бы сделать так, чтобы отдел документации Apple работал над ней согласованно с людьми, месяцами пишущими API. Поэтому сразу в день их выпуска в документации был бы замечательный набор примеров кода, демонстрирующих способы использования API.

Ты совершенно прав, особенно в отношении SwiftUI — проблема в отсутствии традиционной документации… Если зайти в документацию по Text в SwiftUI, то у типа View есть множество различных модификаторов, которые можно применять к этому View. Их количество, кажется, исчисляется сотнями, если не больше. Однако наличие огромного списка всего того, что можно сделать с Text, ничем не помогает. Мы хотим знать следующее: «Как сделать, чтобы текст выглядел так?», «Что если мне нужен многострочный текст?», «Что если я хочу, чтобы многострочный текст состоял из определённого числа строк, после чего выравнивался по середине?» Реализуя подобные вещи, нам нужны примеры. Я не думаю, что общий список случаев, которые люди используют в реальности, особо широк. Я понимаю вашу боль.



На правах рекламы


Воплощайте любые идеи и проекты с помощью наших VDS с мгновенной активацией на Linux или Windows. Сервер готов к работе через минуту после оплаты!

VDSina.ru хостинг серверов
Серверы в Москве и Амстердаме

Комментарии 55

    +15
    Apple: боль как имманентная часть культуры.
      0

      Тут все просто, обычный бизнес.
      Чтобы поддерживать актуальную документацию, Apple нужно потратить деньги на это. Они не хотят, а зачем им это? Айфоны покупают, комиссия в аппсторе платится, свой доход они получают. Документация его никак не увеличит.
      Разработчик хочет написать софт и заработать денег, поэтому он заинтересован в том чтобы разбираться самостоятельно и делает это.

        +14

        "Документация его никак не увеличит."


        У Microsoft всегда была нормальная документация. И с доходами у них тоже всё в порядке. Наверное, это просто так повелось исторически: одни делают документацию, другие не делают, и все считают, что так и надо.

          +16
          Самое интересное у майков есть обертки для эплового апи (я так понимаю это для xamarin) где документация лучше чем в оригинале, так и получается — читаешь доку апи эпла на сайте microsoft )
            +4
            У Microsoft всегда была нормальная документация
            я вполне себе не единожды натыкался на доки с MDSN, где примеры кода попросту не компилировались, потому что не соответствовали стандарту си, а уж более стабильного языка и не назовешь.

            Мне например очень нравилась документация Qt. Чертовски подробная, достаточно многословная, куча нюансов описано и примеров предоставлено. Это до тех пор, пока я не начинал использовать более новые и менее стабильные фичи. И там доходило до того, что на часть моих вопросов могли ответить только 1-2 человека на SO… которые являлись разработчиками тех самых фич (qbs).

            Собственно, судить о документации надо либо очень комплексно, либо не очень категорично. Потому что скорее всего вы испытываете её нехватку потому, что всё хорошо покрытое уже освоили.
              0
              Ну с Qt попроще всё-таки, исходники ведь посмотреть можно. А они весьма читабельные (были, по крайней мере, когда я смотрел)
              +2
              Что? У Microsoft? ))) Сейчас пользуюсь их документацией. Уже навигация и поиск — это дикий ужас. Ищешь доки по C#, тебе подсовывают статьи по VB. Спрашивается, зачем? Многие статьи (сразу подчеркну, не все!) — это просто краткие определения из одного предложения, а дальше сам додумывайся, как пользоваться. Есть правда и хорошие статьи, но только по самым используемым библиотекам, объектам, методам, свойствам. Но стоит только захотеть посмотреть документацию по не самым популярным моментам, приходится собирать информацию по всему интернету по крупицам. Так что MS тоже не образец в составлении документации. До Мозилловской MDN — им как до луны.
                +2
                Так что MS тоже не образец в составлении документации.


                Так я не возражаю. Не идеально, да. Но документация на продукты Microsoft всегда была доступной. Начиная от описания прерываний MS DOS. Наверное, им было нужно привлечь на свою темную сторону побольше программистов.
                +2
                У Microsoft всегда была нормальная документация

                MSDN всегда был помойкой без нормального поиска и даже без обычной древовидной структуры, по которой можно что-то найти.
                  –1
                  Человеческую жадность никто не отменял
                    0
                    Затраты на рисование более новых и выразительных иконок, я уверен, больше, чем на отдел технических писателей. И для конторы размером с Apple/Microsoft это копейки. Просто так повелось, наверное.
                    Результат можно посмотреть на рутрекере, например. Если есть программа для решения какой-то прикладной задачи — она, скорее всего, будет под Windows.
                    0
                    ну я бы поспорил, иногда кроме названия метода ничего нету
                    +18
                    Это нормальная логика для средней руки конторки с ограниченными бюджетами.
                    Но когда ты буквально не знаешь (в буквальном смысле этого слова) куда девать деньги, а на презентациях слово awesome звучит каждые три минуты — это ну никак не тянет на весомую отмазку.
                      +1
                      «Крупная финансовая корпорация возьмёт в аренду дырокол»
                        +2
                        Ну а что, это даже не совсем шутка. Работал в компании, где постоянно надо было подшивать толстые пачки документов. В компании были лишь самые дешевые канцелярские дыроколы, для которых 10-15 листов — это уже испытание. И в один прекрасный момент перед руководством поставили вопрос о покупке хотя бы одного мощного, качественного дырокола на всю компанию. Узнав цену, которая для компании точно не критична, отказали. Ведь можно же дырявить по 5-10 листов и складывать. Так и сказали )))
                      +11
                      «Документация его никак не увеличит.»

                      Лучше документация — меньше порог входа, больше разрабов способных довести дело до конца, больше приложений, больше денег
                        +1
                        меньше документации -> меньше разработчиков, но остаются только те кто смогли, т.е. лучшие из тех кому это было надо. Шучу, но кто его знает
                          0
                          так у эппла всегда так было, еще после Джобса и до Джобса! Они вообще говорили, что это фича — под макось немного разработчиков, но зато самые отборные!
                          –1

                          Больше приложений не значит больше денег.

                        +14
                        Со стороны разработки и внедрения дизайна, могу добавить, что у Apple, худшие гайдлайны.
                        Честно говоря, придя по пути мобильной разработки MS — Android — ios, был сильно удивлен, что почти на любой вопрос чуть более высокой сложности, получаешь ответ в виде «Это Apple детка, решения нет, ищите другой способ». И зачастую решения нет, т.к. как раз нет документации и\или обсуждения проблемы о которая часто известна много лет с разработчиками Apple. (как это делается на других платформах)
                          +3
                          На Android, к сожалению, не лучше. Material Design — худшее, что могло придумать человечество. Если им следовать, то приложения получаются словно плагиат друг-друга с зазженным UI. Human Giudelines в этом плане в несколько раз более гибкие и продуманные. Если уж следовать гайдлайнам, то у Apple они не такие плохие.
                            +8
                            Если им следовать, то приложения получаются словно плагиат друг-друга с зазженным UI.
                            Чем «заезженей» UI, тем он привычней и понятней пользователю. А в дикие фантазии дизайнеров уже наигрались в двухтысячных в вебе, пока не получил доминирование wordpress и bootstrap, задавшие тренд на унификацию дизайна.
                              0
                              Тут, вы, конечно, правы. Но во всем есть разумный предел. Если следовать всем гайдлайнам material design, то получатся одинаковые приложения-клоны, будто созданные в конструкторе.
                                +8
                                Если вы делаете приложение, которое отличается от других только дизайном а не функциональностью, может вы делаете что-то не то? =)
                                Чем более понятный, предсказуемый и унифицированный дизайн тем лучше. Приложения призваны решать задачи а не превращать решение в квест «поиск предметов».
                                  +1

                                  Поддерживаю. Ни разу ещё не удалял приложение из-за недостатка дизайнерских свистоперделок, а вот наоборот — постоянно.

                          +1

                          Немного не по теме. Но хочу высказаться.


                          Самое ужасное для разработке под сафари на js это отладка, под старые устройства.


                          Нет совместимости сафари старой версии на устройстве и новой на макос.
                          Приходится откатывать макос через таймашину или устанавливать ос на более старую, очень удобно.


                          Подвиндоус и андроид такой проблемы нету.
                          Вы конечно можете сказать есть бабл — но это не всегда помогает.

                            0
                            Если надо только JS, может, OS X в KVM помогла бы? Без ускорения GPU, правда.
                              0
                              Как из один вариантов, вот как только подключеный айпат по USB к MacMini пробросить на виртуалку. Я представляю какой это квест.

                              Я вот такое раньше использовал из под линукс github.com/google/ios-webkit-debug-proxy и более менее ратало на айфоне но не на айпаде.
                                –1
                                Да нет особого квеста, одна галочка в vmware.
                              +1
                              А если Parallels использовать?
                                0
                                Я так понимаю это видоус через виртуалку для mac os, если да — то это совсем не то что нужно.
                                Тут борьба физического устройства и невозможности дебажить сайт/веб-приложение средствами Аппл через Safari remote debuger.
                                  0
                                  Это ещё и macOS через виртуалку для macOS, что по идее должно помочь с установкой и использованием более старых версий macOS.
                                    0
                                    Да, точно можно более ранние ставить: www.parallels.com/blogs/run-32-bit-on-mac
                                  +1

                                  Самый простой выход в этой ситуации: BrowserStack (виртуалки с разными версиями браузеров прямо в браузере).

                                    –1

                                    Да этот подход можно, к сожалению, на многие вещи распространить. Иногда кажется, что там сплошные маркетологи управляют: прорекламировали, люди деньги потратили — можно забить.
                                    3D-Touch выпустили — через три года убрали даже на тех устройствах, которые его поддерживают (и на телефонах, и на часах, хотя с ним вызвать действие на меню получалось быстрее).
                                    Поддержку eGPU выпустили — через несколько лет на устпойствах с М1 уже eGPU не поддерживается. Ну а что, пользователи собирали из MacMini практически Mac Pro за лишь малую часть стоимости, разве такое стоит допускать?
                                    Я хоть и не луддит, но с таким отношением я с ужасом боюсь того момента, когда Apple перестанет поддерживать x64. Вот там будет вакханалия самоуправства.
                                    Я к тому, что не только старые устройства, даже относительно новые не в почете. Может даже менее любимы, чем старые, так как их пользователь не так скоро задумается об обновлении. Складывается впечатление, что подталкивают, как могут.

                                    –15
                                    Я понятия не имел, в чём проблема на стороне Apple.
                                    • Отделу документации не дают ...

                                    Понятия и не будет. Проблема не на стороне Apple.

                                    Отделу документации всё дают, но вот разработчики со стороны — это реальная проблема. Миллионы поделок, исполняющих одно и то же. И большинство — убогие. Они просто не нужны. В массе пользователи ифонов пользуют то, что установлено, а что-то добавляют весьма редко. И на андроиде такая же картина. Среднему хомяку нужна просто звонилка с контактами и чатиками. И это всё делают не миллионы мелких начинающих стартапов и считающих себя таковыми одиноких разрабов, а несколько больших контор, у которых с документацией проблем нет, потому что там работают опытные в таком деле разработчики, плюс обеспечивают их хорошо.

                                    Рынок сегодня не для мелочи. А мелочь, как например в подобных статьях, всё ноет и ноет, мол ну когда же они прекратят мне препятствия на пути к миллионам ставить? Но простую вещь понять не могут — зачем им делиться с убогими?

                                    У больших контор всё хорошо, поэтому ничего для вас не изменится. Не смотря на подгорающее чсв, да. Пора бы уже, наконец, посмотреть правде в глаза. Или фраза «ну я же хочу стать миллионером!» весь мозг заполонила? Ну что-ж, бывает. Только мечта сбывается у единиц из миллионов. Посчитайте на досуге, сколько там на миллиард народу цукербергов приходится. Вот такие у вас шансы. Повезёт — выстрелите и без документации. Потом купите тех, кто умеет и с такой документацией. Ну и далее будет легко. А пока это всего лишь нытьё, мол мне, такому бесценному, не дают зарабатывать.
                                      +4

                                      Вы не правы. У Гугла великолепная документация для Флаттера, даже есть канал на Ютубе на котором каждые пару дней появляется новый ролик про очередную фишечку. Хорошее коммьюнити и любовь разработчиков выгодны для любой компании — это и возможность забирать лучшие кадры с рынка и большее количество качественных приложений за которые они получают комиссию.

                                        0

                                        У гугла документация весьма неровная. Некоторые вещи прекрасно задокументированы, некоторые примерно как у Эпла.

                                        0
                                        Это похоже на монополизацию. Как пользователь могу сказать, что у меня стоит почтовый клиент, написанный одним (одним) человеком, и который куда лучше многих продуктов крупных контор. Разработчик его потом продал такой конторе.
                                          0
                                          Это похоже на самую обычную человеческую глупость.

                                          Вот например вы — будете платить разработчику вашего почтового клиента каждый месяц хотя бы рублей по 200-300? Вы уже задумались? А как вы думаете, сколько миллисекунд потребуется большинству хомячков что бы отказаться платить?

                                          Поэтому нужные программы некому разрабатывать. Ведь вы все не готовы за это платить. А кушать автору тоже хочется.

                                          Вы скажете — ну пусть автор на рекламе зарабатывает, пусть вертится, пусть бизнес развивает. Но он-то как раз всё так и делает! И в итоге нектороые авторы дорастают до размеров гугла. И оные гуглы с эпплами дают вам то, что вы имеете. Именно потому, что они по вашему совету не ждали милости от клиентов, а поставили себе задачу взять от вас всё, не спрашивая ваших советов. Ну и теперь диктуют свою волю хомячкам, которым в лом подумать о будущем, которые не хотят платить за то, что можно получить бесплатно, но отстойного качества.

                                          Повторюсь — самая обычная человеческая глупость. Массовая. Которую тупо используют. И результат все видят, но глупость мешает его понять. Думают, что «это похоже на монополизацию», но на самом деле это похоже на отказ людей от желания думать о своём собственном будущем. И вот вам результат.
                                            0
                                            Очень странные и непонятные вещи вы пишете. Почему пользователь должен платить за то, что ему не нужно или больше того, что может заплатить конкуренту? Это проблемы производителя, а не клиента. На практике одни и те же задачи нередко имеют технические решения, различные по стоимости в разы и десятки раз, но одинаковые по качеству. А иногда более дешевые решения более качественны, чем дорогие.
                                            В СССР тоже за всех думали, теперь вот корпорации решили тоже за всех подумать. Неудивительно, что растет спрос на «максимально чистую ось» на устройствах, без приложений, которые пользователю не нужны, но аккуратно собирают о нем максимум информации.
                                            Я два года ходил с Айфоном, но в конце концов меня достало вытягивание денег, странный интерфейс и думание за меня. И судя по тому, что Самсунг отыграл рынок, политика Эппл ведет компанию не туда. Наверное есть люди, которым удобно, что за них думают — вот пусть и покупают продукцию Эппл.
                                            Что же касается почтового клиента — это было одно из немногих приложений под Андроид, которое я купил, и рад за автора, что он его продал. Надеюсь, что недешево, потому что приложение удачное.
                                            Тысячи программистов в мире делают бесплатные продукты, и спасибо им за это. В Западном мире нормальна финансовая благодарность, у нас (как, к слову, и в Индии) — не очень. Это вопрос культуры. Я периодически шлю донаты.
                                              0
                                              >> Почему пользователь должен платить за то, что ему не нужно или больше того, что может заплатить конкуренту?

                                              Вот поэтому вы и потеряли свой почтовый клиент. Вы хотите дёшево и красиво, но так не бывает. Либо вы меняете отношение к чужому труду, либо вас так и будут иметь мега-корпорации. Третьего не дано.
                                                0
                                                Я клиентом как пользовался, так и пользуюсь. И продавший его автор успешно продолжает над ним трудиться, но уже работая на покупателя. Да, после продажи компания попыталась переделать клиент под свои стандарты «хорошего продукта». Но хватило ума отказаться, видимо посмотрели на жалобы и убегающих пользователей.
                                        +2

                                        Эта заметка появилась так во время. Недавно я разбирался с кастомным UICollectionLayout для чата. Там документации просто нет. На тебя выплюнуты какие то факты которые не всегда соответствуют действительности. Ни описания цикла, ни в каком порядке что вызывается. Зачем ходить в SwiftUI когда UIKit наполовину мертвый. Я сидел и постоянно проклинал эпол.

                                          +5

                                          Всё так. Приходится слушать часовые записи "воркшопов" с WWDC в надежде, что покажут хоть как-то релевантный пример, и постоянно сидеть на StackOverflow :(

                                          –1
                                          Иногда у меня возникает ощущение, что из-за такой документации Эппл иногда умудляется делать невероятно простые и глупые ошибки. В стиле ошибки проверки сертификатов в браузере или доступ в систему с пустым паролем админа.
                                            +1
                                            самая лучшая документация по этим новым и важным функциям была спрятана в файлах заголовков. Это отвратительно.

                                            А я как-то привык всегда смотреть в заголовки (да и в исходники, что уж там) вместо рысканья по StackOverflow. По мнению автора, наверное, совсем мерзкое дело.
                                              +2
                                              По работе пишу на Си для процессора Nordic NRF52382. Документация написана в стиле «название функции — список параметров». Зачем эта функция — ни слова. Примеров в документации нет. Есть набор примеров отдельно, только он для старого API, с другими функциями, и с современным API стыкуется весьма опосредовано. Плюс отдельно файл конфигурации этой библиотеки в целом, по которому документации нет вообще — приходится разбираться в многоуровневых #ifdef в исходниках. Хорошо еще эти исходники есть, иначе работать было бы нереально.

                                              Есть форум на сайте, куда иногда забредают разработчики API. Местный функциональный аналог SO.

                                              Это норма в современном мире. В моем случае Nordic получает прибыль с продаж микросхем. Программисты, пишущие API — это статья расходов, они прибыль не приносят. Не удивлюсь, если отдела документации там вообще нет.
                                                –1
                                                У TI тоже самое. Документация на сам процессор относительно норм, но это описание регистров. Чуть более высокоуровнево даже для их RTOS — все, туши свет, кидай гранату.
                                                0

                                                Такие стать очень полезны тем, что возвращают веру в себя. А то, я, признаться, чувствовал себя полным дураком, первый раз увидев SwiftUI после приличного бекграунда на ObjC с классами, ObjC с xib, ObjC и Swift со Storyboard. В Storyboard ты хотя бы мог визуально компонент перекинуть, посмотреть что за класс, потом пойти в доки. Тут сидишь и думаешь: а как тут вставить Х? Нагуглил, вставил. А как его сделать таким? Опять гуглишь. А как вставить Y? Нагуглил, вставил, бац: а два элемента нельзя (если память не изменяет, до сих пор нет простой подсказки в Xcode, что больше одного элемента должны быть обернуты в Stack).

                                                  0
                                                  Ну, начнем с того, что в последние годы дока у эплов вполне себе ничего. Да и раньше была не плохой.
                                                  Отсутствие описания иногда бывает, не успели дописать, через год обычно появляется. Исключения есть, но обычно это что-то старое, хоть и полезное.
                                                  Но что более важно: нельзя узнать как оно работает прочитав описание одного метода. У эплов есть еще руководства (Guidelines) и, более ценные, ролики wwdc. Пока не научился смотреть wwdc тоже не понимал, как можно по доке с чем-то разобраться, особенно когда принципиально новый фреймворк вышел без хорошего описания где-то в начале. А как wwdc начал включать, так оказалось, что норм все.
                                                  Так что не все так однобоко, как кажется.
                                                    0
                                                    Мне кажется, или яблоко само по себе не очень
                                                      0

                                                      Хочешь зарабатывать деньги моей лопатой и требуешь чтобы я черенок отполировал, потому что занозы мешают… А где спасибо за лопату?

                                                        +1
                                                        Выдвину смелое предположение.
                                                        Одной из причин того что доля iOS на рынке сильно меньше Android в том, что для разработки под iOS недостаточно документации.
                                                        Конечно, звучит притянуто. Ведь есть более весомая причина — разрабатывать/публиковать в App Store можно только на компьютере от Apple. Дальше можно привести порог входа в программирование, но он есть и у всех других платформ.
                                                        Достаточно представить желающего создать свое первое приложение под iOS, пусть у него уже есть макбук, а также способности кодить. Он пытается разобраться в доках, а их нет, вдруг обращает внимание что в Android разработке с этим порядок и перекатывается туда. А если бы доки были, то довел бы начатое до конца.
                                                        Так что наличие доков хоть и не полностью перевернет ситуацию на рынке, но разработчиков под iOS и приложений в App Sore прибавится.
                                                        Другой вопрос, в Apple должны же были подсчитать насколько окупится вложение в документацию.
                                                          +1

                                                          Ваше предположение логичное, но не соответствует моему личном опыту и тому что я слышу от знакомых разрабов. Платящая аудитория пользуется айос. Я сам работал в компании и знаю другие случаи когда компания тупо сворачивает вообще разработку под андроид так как нет смысла держать отдел девелоперов ради платформы приносящей 7% дохода. И никого никакие ограничения эпол не останавливают. Или часто могут ковырять андроид только ради охвата рынка, а не ради прибыли. Ситуация приблизительно такая же и в геймдеве. Казалось бы, игры в основном разрабатываются на кроссплатформенных движках, но полируются именно под иос, а зачастую и выходят раньше. Потому что балом правит тот кто платит.

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

                                                        Самое читаемое