Releases: beeware/rubicon-objc
v0.4.9
Features
- Objective-C methods with repeated argument names can now be called by using a
__
suffix in the Python keyword argument to provide a unique name. (#148) - The error message has been improved when an Objective-C selector matching the provided arguments cannot be found. (#461)
Bugfixes
- The handling of structure and union return types was updated to be compatible with changes to ctypes introduced in Python 3.13.0a6. (#444)
Backward Incompatible Changes
- The order of keyword arguments used when invoking methods must now match the order they are defined in the Objective-C API. Previously arguments could be in any order. (#453)
Documentation
- The README badges were updated to display correctly on GitHub. (#463)
Misc
0.4.8
Features
- Name clashes caused by re-registering Objective C classes and protocols can now be automatically avoided by marking the class with
auto_rename
. (#181) - Apple Silicon is now formally tested by Rubicon's continuous integration configuration. (#374)
- Support for Python 3.13 was added. (#374)
- The
__repr__
output forObjCBoundMethod
,ObjCClass
,ObjCInstance
,ObjCMethod
,ObjCPartialMethod
, andObjCProtocol
were simplified. (#432)
Bugfixes
- The
__all__
definition forrubicon.objc
was corrected to use strings, rather than symbols. (#401)
Documentation
- The documentation contribution guide was updated to use a more authoritative reStructuredText reference. (#427)
Misc
0.4.7
Features
- The
__repr__
and__str__
implementations forNSPoint
,CGPoint
,NSRect
,CGRect
,NSSize
,CGSize
,NSRange
,CFRange
,NSEdgeInsets
andUIEdgeInsets
have been improved. (#222) objc_id
andobjc_block
are now exposed as part of therubicon.objc
namespace, rather than requiring an import fromrubicon.objc.runtime
. (#225)
Bugfixes
- References to blocks obtained from an Objective C API can now be invoked on M1 hardware. (#225)
- Rubicon is now compatible with PEP563 deferred annotations (
from __future__ import annotations
). (#308) - iOS now uses a full
NSRunLoop
, rather than aCFRunLoop
. (#317)
Backward Incompatible Changes
- Support for Python 3.7 was dropped. (#334)
Documentation
- All code blocks were updated to add a button to copy the relevant contents on to the user's clipboard. (#300)
Misc
- #295, #296, #297, #298, #299, #301, #302, #303, #305, #306, #307, #310, #311, #312, #314, #315, #319, #320, #321, #326, #327, #328, #329, #330, #331, #332, #335, #336, #337, #338, #341, #342, #343, #344, #345, #346, #348, #349, #350, #351, #353, #354, #355, #356, #358, #359, #360, #361, #362, #363, #364, #365, #366, #367, #368, #369, #370, #371, #372, #373, #375, #376, #377, #378, #379, #380
0.4.6
0.4.5
0.4.5rc1
Due to an incompatibility with Toga 0.3.0dev39, Rubicon-ObjC 0.4.4 was yanked from PyPI. This RC1 release was published so that development versions of Toga could access the bug fixes contained in that release.
Features
- Support for Python 3.6 was dropped. (#371)
Misc
v0.4.4
Due to an incompatibility with Toga 0.3.0dev39, Rubicon-ObjC 0.4.4 was yanked from PyPI.
Bugfixes
- Background threads will no longer lock up on iOS when an asyncio event loop is in use. (#228)
- The ObjCInstance cache no longer returns a stale wrapper objects if a memory address is re-used by the Objective C runtime. (#249)
- It is now safe to open an asyncio event loop on a secondary thread. Previously this would work, but would intermittently fail with a segfault when then loop was closed. (#250)
- A potential race condition that would lead to duplicated creation on ObjCInstance wrapper objects has been resolved. (#251)
- A race condition associated with populating the ObjCClass method/property cache has been resolved. (#252)
Misc
v0.4.3
v0.4.2
v0.4.1
Features
-
Added official support for Python 3.9. (#193)
-
Added official support for macOS 11 (Big Sur). (#195)
-
Autorelease Objective-C instances when the corresponding Python instance is destroyed. (#200)
-
Improved memory management when a Python instance is assigned to a new
ObjCInstance
attribute. (#209) -
Added support to declare weak properties on custom Objective-C classes. (#210)
Bugfixes
-
Fixed incorrect behavior of
Block
when trying to create a block with no arguments and using explicit types. This previously caused an incorrect exception about missing argument types; now a no-arg block is created as expected. (#153) -
Fixed handling of type annotations when passing a bound Python method into
Block
. (#153) -
A cooperative entry point for starting event loop has been added. This corrects a problem seen when using Python 3.8 on iOS. (#182)
-
Improved performance of Objective-C method calls and
ObjCInstance
creation in many cases. (#183) -
Fix calling of signal handlers added to the asyncio loop with CFRunLoop integration. (#202)
-
Allow restarting a stopped event loop. (#205)
Deprecations and Removals
-
Removed automatic conversion of Objective-C numbers (
NSNumber
andNSDecimalNumber
) to Python numbers when received from Objective-C (i.e. returned from an Objective-C method or property or passed into an Objective-C method implemented in Python). This automatic conversion significantly slowed down every Objective-C method call that returns an object, even though the conversion doesn't apply to most method calls. If you have code that receives an Objective-C number and needs to use it as a Python number, please convert it explicitly usingpy_from_ns
or an appropriate Objective-C method.As a side effect,
NSNumber
andNSDecimalNumber
values stored in Objective-C collections (NSArray
,NSDictionary
) are also no longer automatically unwrapped when retrieved from the collection, even when using Python syntax to access the collection. For example, ifarr
is aNSArray
of integerNSNumber
,arr[0]
now returns an Objective-CNSNumber
and not a Pythonint
as before. If you need the contents of an Objective-C collection as Python values, you can usepy_from_ns
to convert either single values (e.g.py_from_ns(arr[0])
) or the entire collection (e.g.py_from_ns(arr)
). (#183) -
Removed macOS 10.12 through 10.14 from our automatic test matrix, due to pricing changes in one of our CI services (Travis CI). OS X 10.11 is still included in the test matrix for now, but will probably be removed relatively soon. Automatic tests on macOS 10.15 and 11.0 are unaffected as they run on a different CI service (GitHub Actions).
Rubicon will continue to support macOS 10.14 and earlier on a best-effort basis, even though compatibility is no longer tested automatically. If you encounter any bugs or other problems with Rubicon on these older macOS versions, please report them! (#197)