Xcode mac os для чего нужна

[FAQ] Почему Xcode занимает так много места на диске?

Если вы хотите увидеть на нашем сайте ответы на интересующие вас вопросы обо всём, что связано с техникой, программами и сервисами Apple, iOS или Mac OS X, iTunes Store или App Store, задавайте их через форму обратной связи. Ответы на самые интересные из них будут появляться в материалах данной рубрики. К нам поступил следующий вопрос:

За год работы с Xcode я убедился, что он может сожрать чуть ли не всё свободное место на диске мака( Скачиваешь 2 с лишним гига из апп стора, они распакуются и занимают уже чуть ли не 10 ГБ. И это только в Applications! Ещё полно всего хранится в Application Support. Короче, по моему опыту, через несколько месяцев после установки Xcode отъедает больше 30 ГБ пространства.

А вопрос вот в чем – может, подскажете, какие файлы Xcode можно стереть без ущерба для процесса разработки?

Это вас не сильно порадует, но приведённые вами цифры – ещё цветочки по сравнению с тем, что бывает. Если Xcode не переустанавливать начисто, спустя год-полтора он может занять все 80 ГБ.

Поэтому всё зависит от того, ограничены ли в трафике или во времени. Если нет, разумно периодически удалять Xcode полностью, в частности, стирать:

• само приложение из папки Applications
• папку /Library/Developer
• папку

/Library/Developer (на всякий случай напомним, что тильда означает вашу домашнюю директорию, например, /Users/Vitalik)

Но если целиком переставлять Xcode не хочется, а место освободить надо, можем предложить разобраться с главными пожирателями места на диске.

Обычно лидер по объёму пространства – папка

/Library/Developer/Xcode/iOS DeviceSupport. Она нужна только для целей дебаггинга и анализа логов падения программы на определённой версии iOS. Беда в том, что при каждом подключении устройства с новым билдом iOS в этой папке создаётся вложенная директория размером от 2 до 3 ГБ. Например, вот так структура этой папки выглядит у автора материала:

Стирание содержимого этой папки безопасно, но помните, что она заполняется автоматически. Например, если вы сотрёте подпапку для iOS 9.2, а потом подключите к Маку iPhone с этой версией iOS и запустите Xcode, подпапка создастся снова.

Второе место среди пожирателей места занимают ненужные симуляторы iOS. Каждый может весить от 1,5 до 3 ГБ, но далеко не каждый вам реально нужен. Например, если ваше приложение не рассчитано под iPad, требуется ли вам симулятор? И нужны ли симуляторы вообще, если вы, к примеру, тестируете все билды на «живых» устройствах?

Удалять симуляторы можно прямо в Xcode (правда, эта возможность появилась сравнительно недавно). В верхнем меню выберите пункт Window-Devices (или нажмите Cmd+Shift+2). Удалять ненужные симуляторы можно из контекстного меню пунктов в сайдбаре слева.

Наконец, много ненужного места может отъедать дополнительная документация по старым SDK. Проверьте содержимое папки

/Library/Developer/Shared/Documentation/DocSets и удалите его при необходимости.

Надеемся, количество свободных гигабайт на вашем Маке после этого увеличится.

Источник

Additional XCode SDK — что это такое, и почему вам это не нужно

Apple привносит в мир много нового. Удачные нововведения приживаются, а неудачные понемногу отмирают. Кстати неудачных решений оказывается не так уж и мало и я считаю это абсолютно нормальным. В конце концов мы уважаем Apple именно за готовность идти на риск и экспериментировать:)

Все это в полной мере относится и к средствам разработки. В прошлой заметке я писал о нестандартном алгоритме поиске заголовочных файлов в XCode. Сегодня я хочу подробнее остановиться на так называемых SDK — в XCode этим термином называют комплект библиотек и заголовочных файлов под определенную версию iOS или Mac OS. Зачем нужны SDK в понимании xCode?

• Каждый SDK лежит в своей отдельной папке и безболезненно сосуществует в другими SDK — это позволяет вести разработку под разные ОС на одном компьютере. Раньше SDK лежали в /Developer/SDKs; к четвертой серии xCode они переехали внутрь xCode.app.
• Настроить проект под определенную версию OS — плевое дело. Достаточно указать SDK в настройках проекта.

Технически, это реализовано следующим образом. Apple добавила в компилятор ключ —sysroot. Значение sysroot дописывается как префикс в пути для поиска заголочных файлов и библиотек. Этой модификации подвержены как стандартные пути (ex: /usr/include), так и пользовательские пути, добавленные ключами -I и -L.

Работает это следующим образом. Допустим в настройках XCode выбран SDK macosx10.6. XCode передает компилятору ключ —sysroot=/Developer/SDKs/MacOSX10.6.sdk. В результате /usr/include превращается в /Developer/SDKs/MacOSX10.6.sdk/usr/include. То же самое происходит с путями для поиска библиотек и фреймворков. Как легко догадаться, внутри SDK есть usr/include и usr/lib с соответствующим содержимым.

Теперь самое время перейти к загадочной опции «Additional SDKs» в XCode.

Зачем это нужно? Допустим вы — компания, выпускающая middleware. Вы оформляете свои библиотеки и фреймворки в виде XCode SDK. Чтобы использовать ваш middleware в проекте, достаточно указать полный путь до вашего SDK в разделе Additional SDKs в настройках XCode. Заголовочные файлы и библиотеки становятся доступны автоматически.

Кстати, можно использовать много дополнительных SDK одновременно.

К сожалению, как это часто бывает, красивую идею губит реализация.

Для поддержки Additional SDKs, XCode приходится проделывать много дополнительной работы, что проявляется тормозами при сборке проекта. Для каждого используемого сочетания базового и дополнительных SDK, во временной папке создается объединенное дерево файлов из всех SDK и путь до этой папки передается в —sysroot. Вместо честного копирования файлов используются симлинки, но все равно процесс не быстрый.

Для желающих экспериментировать с Additional SDK, я подготовил проект на github. Обратите внимание на SDKSettings.plist. Этот файл необходим, чтобы XCode «признал» SDK.

В своих проектах я не использую Additional SDK и вместо этого вручную настраиваю пути для поиска хидеров, библиотек и фреймворков.

Бонус: SDK и версии ОС

Для каждой очередной версии ОС выходит новый SDK. Однако это не значит, что проект, скомпилированный с macosx10.8 SDK будет работать только на Mac OS X 10.8 и не запустится на более ранних ОС.

Версия SDK 10.8 означает, что SDK включает в себя все API которые доступны в Mac OS X 10.8 и более ранних системах (за исключением deprecated API). Если проект не использует возможностей, которые отсутствуют в OS X 10.6, тогда проект будет без проблем работать на 10.6.

Более интересная ситуация, когда мы задействуем новые фичи, если они доступны, а для старых систем используем альтернативную реализацию. Для этого используется weak linking. «Слабо прилинкована» может быть как целая динамическая библиотека, так и отдельная функция из динамической библиотеки. Если при запуске не удается найти слабо прилинкованную библиотеку, программа продолжит выполняться как ни в чем не бывало, а линкер подставит NULL в качестве адреса отсутствующих функций. Разумеется, если вызвать функцию, которой нет, программа упадет.

Поэтому перед вызовом мы сравниваем адрес функции с NULL, и если функция не доступна, используем альтернативную реализацию.

Источник

Xcode 4+

Apple

• • 2,5 • Оценок: 3,3 тыс.

• • Бесплатно

Снимки экрана

Описание

Xcode includes everything developers need to create great applications for Mac, iPhone, iPad, Apple TV, and Apple Watch. Xcode provides developers a unified workflow for user interface design, coding, testing, and debugging. The Xcode IDE combined with the Swift programming language make developing apps easy and fun.

Xcode includes the Xcode IDE, Swift and C/C++/Objective-C compilers, Instruments analysis tool, simulators, the latest SDKs, and hundreds of powerful features:

Innovative tools help you create great apps
• Swift is an intuitive programming language that is safe, fast, and modern
• SwiftUI is a revolutionary framework to create user interfaces with a declarative Swift syntax
• Playgrounds are a fun way to experiment and interact with Swift code
• View debugging shows a 3D stack of all your app’s UI view layers at runtime
• Split editors in virtually unlimited ways, show previews, or choose an assistant to see related content
• Live issues display errors as you type, and Fix-its improve your code with just a click
• Source control navigator and service integrations help you manage code across a team

SwiftUI and Interface Builder make it easy to design your interface
• SwiftUI uses declarative Swift code that clearly describes your interface
• Design canvas graphically builds UI views using the library of controls and modifyers
• Preview SwiftUI code or UIKit interfaces in different screen sizes, orientations, and font sizes
• SwiftUI code is always in perfect sync with the graphical design canvas and previews
• Animations are built using simple commands that describe the action you want to see

Professional editor and debugger keep your code front and center
• Refactoring makes it easy to modify the structure of Swift, Objective-C, C, and C++ code
• Open Quickly instantly opens any file within your project
• Data tips and Quick Look can inspect a variable by hovering your mouse over code while debugging

Instruments for performance analysis
• Compare CPU, disk, memory, and GPU performance as graphical tracks over time
• Identify performance bottlenecks, then dive deep into the code to uncover the cause
• Analyze your app directly, or sample the entire system with very little overhead
• Create custom instruments with unique visualizations to analyze your own code and frameworks

To test or run applications on an iPhone, iPad, Apple TV, or Apple Watch all you need is a free Apple ID. To submit your apps to the App Store you must be a member of the Apple Developer Program. Some features may require Internet access.

Источник

Создание программ для Mac OS X. Часть 2: средства разработки и создание простого приложения

В этой части я расскажу вам о средствах разработки приложений под Mac OS X Leopard. Скажу сразу, что буду рассматривать только те, которые предоставляются самой Apple. Другие IDE существуют, но они обычно кроссплатформенные (например Code::Blocks), так что рассказывать о них лучше не в этой статье.

Так вот, на диске с Лео идет инструментарий разработчика Mac OS X — набор необходимых программ и фреймворков для создания приложений. Устанавливается все это дело(приложения, документация, куча примеров, разные полезные утилиты, etc.) в папку /Developer.

После установки имеет 4 основных приложения для разработки:
1. XCode — основная IDE
2. Interface Builder — программа для создания интерфейсов прораммы, хотя ее возможности куда шире
3. Instruments — средство для слежения за программой
4. Dashcode — программа для создания виджетов для Dashboard

А теперь про эти приложения подробнее:
/*многие картинки кликабельны*/

Xcode

Xcode — основная среда разработки, есть все, что и положено для IDE. Расписывать все функции нет особого смысла, т.к. она не сильно отличается от Visual Studio или KDevelop. А вот про нововведения в версии 3.0 упомянуть стоит:

1.подсветка блоков кода:

2. сворачивание(folding) блоков кода(наконец-то)
3. улучшеный(в сторону скорости работы) редактор кода
4. рефракторинг кода

5. поддержка Objective-C 2.0
6. Research Assistant — помощник, который исходя из выделенного текста пытается найти подходящую статью в Help и выводит в своем окне

7. показ ошибок, предупреждений, etc прямо в коде:

8. снимки проекта. Очень удобная вещь, по нажатию клавиш Ctrl+Command+S текущий проэк сохраняется в отдельное место, и потом можно будет к нему вернутся, если что-нибудь намудрил, причем для каждого файла показывается разница между тем что было и что стало:

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

Interface Builder

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

Для чего же используется IB в процессе создания программы? Только для раскидывания кнопочек по форме — нет. Одна из основных задач IB — связывать объекты друг с другом, с переменными в классе, с разными событиями и т.п.

Instruments

Instruments — средство для слежения за приложениями. Построен на порте под Mac OS X «DTrace tracing framework» из OpenSolaris. Само слежение проходит с помощью отдельных инструментов, которые хранятся в библиотеке и при необходимости перетаскиваются в главное окно. Изначально уже есть много инструментов, например инструмент для слежения за сетевой активностью, загрузкой процессора, чтения-записи на диск. Если нужного инструмента не хватает, то можно его создать самому:

Dashcode

Я думаю из названия понятно для чего предназначена эта программа, а именно — создания виджетов для Dashboard. Баловался програмкой не долго, процесс создания виджета напомнил работу в Macromedia Flash. Вот сделал виджет для чтения rss хабра за секунд 10:

Создание простого приложения средствами Xcode и Interface Builder

Как я и обещал, сейчас мы создадим простое приложение. Что оно будет делать? После ввода текста в поле редактирования и нажатия Enter выводить введенный текст на поле надписи(label). Предупрежу, что не буду подробно рассказывать почему что-то надо сделать именно так, мат.часть пойдет потом, сейчас — простое создание приложения без лишних вопросов.

Итак начнем:
открываем Xcode и выбираем в меню File => New Project, в появившемся окне отмечаем «Cocoa Application» и нажимаем Next:

Далее зададим имя проекта — habr_1 и где он будет хранится(у меня

/xcode/habr_1/):

после этого нажмем Finish и получим проект. Теперь нам нужно добавить класс, который будет реализовать то, что нам нужно. Для этого идем в меню File => New File… и выбираем Objective-C class и жмем Next. В следующем окне нас попросят задаять имя файла, так что пишем «controller»:

Теперь в окне проекта слева в папке Classes появились два файла: controller.h и controller.m. Откроем controller.h и напишем тоже, что и на картинке:

Теперь два раза кликнем по файлу MainMenu.nib, откроется Interface Builder и станет активным. Что мы видим: заготовку под окно, главное меню и окно, обозначающее что мы открыли MainMenu.nib. Нажмем в меню Tools => Library чтобы открыть библиотеку с объектами и Tools => Inspector чтобы видеть свойства этих самых объектов. Теперь нам надо добавить в MainMenu.nib объект, который будет представлять созданный нами класс «controller», так что в библиотеке находим объект NSObject(синий полупрозрачный кубик) и перетаскиваем его в окно с надписью MainMenu.nib:

Переименуем «Object» в «controller» для ясности. Теперь нужно объяснить этому кубику, что он представляет нужный нам класс. Для этого оставляя его активным переходим на вкладку «Identity»(вторя справа) в инспекторе и в выпадающем списке напротив надписи «Class» выбираем наш «controller»:

Теперь добавим на форму из Библиотеки поле редактирования и метку. Для поля редактирования в на вкладке «Attributes»(первая слева) в выпадающем списке напротив надписи «action» выберем «Sent On Enter Only». Должно получится примерно такое:

А теперь начинается самое интересное, мы должны связать переменную «label» из класса с меткой и задать «setText:» в качестве сообщения, которое посылает текстовое поле при окончании редактирования. Свяжем метку с переменной label: сделаем активным наш объект «controller», зажмем Ctrl и левую кнопку мыши над синим кубиком и перенесем курсор на нашу метку, увиди следующюю картину:

после отпускания лкм появляется вот такое окно(в нем будут все классовые переменные, которые по типу совпадают с тем, к чему мы пытаемся связать):

выбираем в нем единственную запись label. Все, теперь мы связали класовую переменную label и нашу метку на форме. Связывание полz редактирования с посылаемым ей сообщением проходит также, только перетягивать надо не с кубика на поле, а наоборот — с поля редактирования на объект controller.

Все, сохраняем MainMenu.nib(File => Save) и возвращаемся в Xcode.

В Xcode открываем файл controller.m и описываем реализацию сообщения:

Сохраняем проект, нажимаем Build and Go и получаем готовое приложение:

Введем что-нибудь в поле редактирования и нажмем Enter, вот результат:

Мощь Interface Builder

А сейчас я покажу вам как IB может упростить жизнь и количество кода. Создадим почти приложение(почти потому, что откомпилировать в полноценное приложение). Что оно будет делать? Выводить состояние слайдера в поле редактирования и иметь кнопку для закрытия.

Итак начнем. Откроем Interface Builder, File => New, выбираем «Window» и клацаем «Choose», получаем окно «Untitled», обозначающее наше окно и заготовку окна, кидаем на нее горизонтальный слайдер, поле редактирования и кнопку, причем в свойствах обзываем ее «Close»:

Теперь проводим связь _от слайдера_к_полю_редактирования_, после отпускания лкм в выпадающем списке выбираем «takeDoubleValueFrom:»:

Аналогично свяжем кнопку с событием terminate: объекта «First Responder» из окна «Untitled»(красненький кубик с единичкой).

Теперь File => Simulate Interface, получаем прототип работоспособного приложения: при изменении положения слайдера изменяется число в поле редактирования, при нажатии на Close приложение закрывается.

Вот так просто можно избавить себя от написания многих строк кода.

А если кто еще не убедился в этом, то посмотрите это видео. В нем сам ОН(не, не RMS) рассказывает и показывает всю мощь Interface Builder(правда перед этим минут 30 пиара NextSTEP):

Источник